On Mon, Aug 24, 2020 at 10:28:23AM -0400, Brian Foster wrote: > Do I understand the current code (__bio_try_merge_page() -> > page_is_mergeable()) correctly in that we're checking for physical page > contiguity and not necessarily requiring a new bio_vec per physical > page? Yes. > With regard to Dave's earlier point around seeing excessively sized bio > chains.. If I set up a large memory box with high dirty mem ratios and > do contiguous buffered overwrites over a 32GB range followed by fsync, I > can see upwards of 1GB per bio and thus chains on the order of 32+ bios > for the entire write. If I play games with how the buffered overwrite is > submitted (i.e., in reverse) however, then I can occasionally reproduce > a ~32GB chain of ~32k bios, which I think is what leads to problems in > I/O completion on some systems. Granted, I don't reproduce soft lockup > issues on my system with that behavior, so perhaps there's more to that > particular issue. > > Regardless, it seems reasonable to me to at least have a conservative > limit on the length of an ioend bio chain. Would anybody object to > iomap_ioend growing a chain counter and perhaps forcing into a new ioend > if we chain something like more than 1k bios at once? So what exactly is the problem of processing a long chain in the workqueue vs multiple small chains? Maybe we need a cond_resched() here and there, but I don't see how we'd substantially change behavior.
