[Cc:ed in the xfs list to ask a question: see the last quoted section below] On 23 Apr 2018, Avery Pennarun stated: > On Mon, Apr 23, 2018 at 1:44 PM, Nix <nix@xxxxxxxxxxxxx> wrote: >> Hm. Checking the documentation it looks like the scheduler is smarter >> than I thought: it does try to batch the requests and service as many as >> possible in each sweep across the disk surface, but it is indeed only >> tunable on a systemwide basis :( > > Yeah, my understanding was that only cfq actually cares about ionice. Yes, though idle versus non-idle can be used by other components too: it can tell bcache not to cache low-priority reads, for instance (pretty crucial if you've just done an index deletion, or the next bup run would destroy your entire bcache!) > That's really a shame: bup does a great job (basically zero > performance impact) when run at ionice 'idle" priority, especially > since it uses fadvise() to tell the kernel when it's done with files, > so it doesn't get other people's stuff evicted from page cache. Yeah. Mind you, I don't actually notice its performance impact here, with the deadline scheduler, but part of that is bcache and the rest is 128GiB RAM. We can't require users to have something like *that*. :P (heck most of my systems are much smaller.) > On the other hand, maybe what you actually want is just cfq with your > high-priority tasks given a higher-than-average ionice priority. I The XFS FAQ claims that this is, ah, not good for xfs performance, but this may be one of those XFS canards that is wildly out of date, like almost all the online tuning hints telling you to do something on the mkfs.xfs line, most of which actually make performance *worse*. xfs folks, could you confirm that the deadline scheduler really is still necessary for XFS atop md, and that CFS is still a distinctly bad idea? I'm trying to evaluate possible bup improvements before they're made (involving making *lots* of I/O requests in parallel, i.e. dozens, and relying on the I/O scheduler to sort it out, even if the number of requests is way above the number of rotating-rust spindles), and it has been put forward that CFS will do the right thing here and deadline is likely to be just terrible. <http://xfs.org/index.php/XFS_FAQ#Q:_Which_I.2FO_scheduler_for_XFS.3F> suggests otherwise (particularly for parallel workloads such as, uh, this one), but even on xfs.org I am somewhat concerned about stale recommendations causing trouble... -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
