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. -- Coly Li
