Hello Coly, I agree with you wholeheartedly, which was the reason for my patch and email. But you seem to have gotten it the wrong way around. You see, ever since https://github.com/torvalds/linux/commit/b41c9b0266e8370033a7799f6806bfc70b7fd75f was merged into bcache in late 2017 any IO flagged as REQ_RAHEAD or REQ_BACKGROUND is simply skipped (bypassed) and no longer considered for caching at all, regardless of IO pattern. If what you say holds true, it sounds like that patch was wrongfully merged back then, as it has introduced the behaviour you do not want now. If you believe it makes an exception for sequential FS metadata, I would very much like you to review that patch again, as that is not the case. My patch on the other hand aims to revert this change by default, so it is all about IO patterns again, but make it configurable for users who want this new behaviour. Am 2019-02-16 um 1140 schrieb Coly Li: > On 2019/2/15 11:25 下午, Andreas wrote: >> Dear ladies and gentlemen, >> >> I created a patch to make the bypasses for readahead and background IO >> that were added in late 2017 configurable via SysFS switches. Since >> receiving that original patch in my distro's kernel I noticed >> performance degradation and found a few people asking about similar >> symptoms as I noticed online who weren't able to identify the problem. >> >> I have more details and my new patch itself outlined at >> https://gitlab.com/snippets/1820316, for convenience I have attached >> that same patch to this email. >> >> I just thought this may be interesting to you and wanted to let you >> know. Do with it as you please. >> >> With kind regards >> Andreas >> > Hi Andreas, > > Bcache does not care too much about whether it is readahead or > background I/O. What it cares is the I/O pattern, a.k.a random or sequence. > > The reason we care about metadata here is, for some file systems, they > do metadata readahead as sequential requests, and we want to keep such > sequential metadata I/Os on cache device. > > For normal file readahead, if it is sequential I/O and execeeds > sequential cutoff threshold, bcache won't have it. But if it is random, > bcache may have it. It is about I/O patterns, not priorities. > > Your patch introduces cache policy with different I/O priorities > (background or readahead), which may have overlap with I/O patterns, > e.g. a background & random I/O. For such I/O, should we can it or not ? > > Your patch might work and solve your problem, but it makes cache > behavior more explicated and unpredictable (e.g. people may wonder why > random background I/Os are not cached). Therefore I don't plan to take > it for upstream at this moment. > > Thanks. >
