Re: bupsplit.c copyright and patching

[Nix <nix@esperi.org.uk>]

[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@esperi.org.uk> 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...