Re: [PATCH 1/3] bcache: introduce bcache sysfs entries for ioprio-based bypass/writeback hints

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

On 5 Oct 2020, Eric Wheeler verbalised:

> [+cc:bcache and blocklist]
>
> (It did not look like this was being CC'd to the list so I have pasted the 
> relevant bits of conversation. Kai, please resend your patch set and CC 
> the list linux-bcache@vger.kernel.org)

Oh sorry. I don't know what's been going on with the Cc:s here.

> I am glad that people are still making effective use of this patch!

:)

> It works great unless you are using mq-scsi (or perhaps mq-dm). For the 
> multi-queue systems out there, ioprio does not seem to pass down through 
> the stack into bcache, probably because it is passed through a worker 
> thread for the submission or some other detail that I have not researched. 

That sounds like a bug in the mq-scsi machinery: it surely should be
passing the ioprio off to the worker thread so that the worker thread
can reliably mimic the behaviour of the thread it's acting on behalf of.

> Long ago others had concerns using ioprio as the mechanism for cache 
> hinting, so what does everyone think about implementing cgroup inside of 
> bcache? From what I can tell, cgroups have a stronger binding to an IO 
> than ioprio hints. 

Nice idea, but... using cgroups would make this essentially unusable for
me, and probably for most other people, because on a systemd system the
cgroup hierarchy is more or less owned in fee simple by systemd, and it
won't let you use cgroups for something else, or even make your own
underneath the ones it's managing: it sometimes seems to work but they
can suddenly go away without warning and all the processes in them get
transferred out by systemd or even killed off.

(And as for making systemd set up suitable cgroups, that too would make
it unusable for me: I tend to run jobs ad-hoc with ionice, use ionice in
scripts etc to reduce caching when I know it won't be needed, and that
sort of thing is just not mature enough to be reliable in systemd yet.
It's rare for a systemd --user invocation to get everything so confused
that the entire system is reundered unusable, but it has happened to me
in the past, so unlike ionice I am now damn wary of using systemd --user
invocations for anything. They're a hell of a lot clunkier for ad-hoc
use than a simple ionice, too: you can't just say "run this command in a
--user", you have to set up a .service file etc.)