Hey! Am Sa., 15. Sep. 2018 um 21:47 Uhr schrieb Coly Li <colyli@xxxxxxx>: > On 9/15/18 10:35 PM, Kai Krakow wrote: > > In the past (I think back in 4.9), Eric sent some interesting writeback > > hinting patches which I still carry around rebasing them with every > > kernel version. I'm not sure if everything is still okay with these > > patches or if I missed something during rebase, but my system is stable > > with these. > > > > Background: These patches allow processes with low IO priority to bypass > > the bcache and thus reduce write load on the SSD. This is useful for > > maintenance and backup jobs. It also ensures that such jobs won't > > dominate the bcache and increases the chance of keeping important data > > in the bcache. OTOH, important and IO sensitive processes can be made to > > always use the bcache even when sequential cutoff would normally read > > directly from the backing device bypassing bcache. > > > > I wonder if there's still activity around this? Eric seems to have been > > very silent AFAIT. > > > > Are there chances to get this upstream? I remember there was some > > discussion around this. If someone is interested, I can keep these > > patches rebased in a public repo - or maybe someone with more insight in > > bcache offers to do that. > > > > Any thoughts on this? I think, Eric made some valuable patches which > > allow lowering wear on SSDs. > > Hi Kai, > > Last time when this series was discussed, I remember there was opinion > that the interface was complicated. > > IMHO we can simplify the interface by only input class level number to > the sysfs interface, e.g. > > echo 7 > /sys/block/bcache0/bcache/ioprio_bypass > echo 0 > /sys/block/bcache0/bcache/ioprio_writeback > > From Eric's document, behavior of I/O class 1 and 3 are always same, > the only thing can be changed is for I/O class 2. I may handle it in > other following changes. I don't think this is the case. But the documentation may be misleading in this regard. You may specify echo 1,3 > /sys/block/bcache0/bcache/ioprio_bypass to bypass the bcache if ioprio is class 1 prio >= 3, which would also bypass class 2, and 3. At least this is what admin-guide/bcache.rst tells me. But I wonder what happens if you specify something which would hint bypass and writeback at the same time. Probably, in this case sysfs should just reply with "invalid argument" or whatever is a reasonable choice. > In general this series is OK to me, we just need to design a simpler > interface. I may add them into my for-test directory, to test and > understand how it works, and then improve it if necessary. Given the documentation, I don't see how this could be made simpler. It's just not as simple to understand. But if we think of class+prio as a 2-digit number (an octal number if you want to), as CP with C = class and P = prio, then it becomes pretty simple: process 0CP < writeback 0CP --> always writeback process 0CP >= bypass 0CP --> always bypass writeback 0CP >= bypass 0CP is obviously an invalid setting. (leading zero indication octal notation) That is, the example gives 027 = bypass 000 = writeback Since a process whatever priority would never have 0CP < 000, that's why it's disabled in this case. But nothing prevents me from putting 1,3 into the bypass config. It would result in the realtime class prio >= 3 being bypassed. Hinting of writeback probably defaults to disabled because (a) no one wants it without explicit knowledge, and distribution do not use class 1 for any process AFAIT, so it makes no sense to set writeback=2,0 or even below. B4 is the default setting of linux processes (best-effort, class 2, prio 4). I've set some processes to B0. I'd probably configure writeback=2,1 for those, or maybe even 2,4. But, conclusion: It can be changed. :-) Thanks, Kai
