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@xxxxxxxxxxxxxxx) 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.)
