LWN: Comments on "Predictive per-task write throttling" https://lwn.net/Articles/152635/ This is a special feed containing comments posted to the individual LWN article titled "Predictive per-task write throttling". en-us Sat, 27 Sep 2025 00:42:40 +0000 Sat, 27 Sep 2025 00:42:40 +0000 https://www.rssboard.org/rss-specification lwn@lwn.net Performance degradation? https://lwn.net/Articles/153766/ https://lwn.net/Articles/153766/ huaz Hans Reiser claims this patch degrades Reiser4 performance substantially.<br> Thu, 29 Sep 2005 20:18:59 +0000 Predictive per-task write throttling https://lwn.net/Articles/153704/ https://lwn.net/Articles/153704/ jimwelch Arg!, Andrea needs to be promoted to Commodore Andrea for this one. A simple, elegant fix for a complex, long standing problem! Maybe that should be Admiral Andrea. (AA) harg-harg! (Ok, so I'm a little late for pirate day, real life is always a drag on free(as in FOSS) time.)<br> Thu, 29 Sep 2005 15:44:06 +0000 Good news https://lwn.net/Articles/153599/ https://lwn.net/Articles/153599/ ringerc This has driven me nuts for years. Anything that improves the situation is wonderful in my book. Currently, running a backup on my dual Xeon server at work (on an 8-disk RAID) will cause everything else to slow to a crawl for hours. Worse, I have no way to tell the kernel "this is a low priority process, please don't let it monopolize memory or disk resources if someone else wants them," nor can I tell the kernel "this process is just doing a once-off copy, please don't shove everything it reads into your IO cache."<br> <p> A `disknice' command would make me want to send a few cases of nice beer to whoever wrote it. A `memnice' command in the same style, for tuning the amount of system cache memory given to a process, would probably demand a container of beer if only I could provide it. Someone who fixes the kernel so neither is required at all ....<br> <p> Consider a system with a large pile of GUI apps running. It needs the binaries for these apps in RAM, along with things like mailbox index files, various common config files, etc. Now imagine that a backup has pushed all that out of RAM in favour of data that's only going to be used once, so the GUI processes need to read it in from disk now every time they want to use it. That includes the binary images themselves. That's bad, but what's worse is that the backup is slowing disk I/O right down with no way to throttle it, so each access those GUI apps make takes forever. You now have the recipe for how to almost DoS a Linux terminal server by running a backup.<br> <p> I still don't understand why `tar' and `cp' can't just tell the kernel "this read should not be cached" and "I'm doing bulk I/O".<br> Thu, 29 Sep 2005 08:52:01 +0000 Predictive per-task write throttling https://lwn.net/Articles/152640/ https://lwn.net/Articles/152640/ Quazatron This is very good news, as I have been noticing this exact problem for a while. When you think the kernel is already very good, someone steps in and makes it better... You gotta love free/libre/open source software...<br> Wed, 21 Sep 2005 22:10:42 +0000 Predictive per-task write throttling https://lwn.net/Articles/152638/ https://lwn.net/Articles/152638/ arcticwolf I think you accidentally posted the whole article as the summary (so even non-subscribers can read it on the headlines page, I assume). :)<br> <p> Wed, 21 Sep 2005 22:01:17 +0000 Predictive per-task write throttling https://lwn.net/Articles/152637/ https://lwn.net/Articles/152637/ yokem_55 This is marked as a subscriber article, but the full text of the article is on the front news page even for non-subscribers. Something not work right?<br> Wed, 21 Sep 2005 22:00:56 +0000