On Sat, Aug 22, 2020 at 02:13:12PM +0100, Christoph Hellwig wrote: > On Sat, Aug 22, 2020 at 07:53:58AM +1000, Dave Chinner wrote: > > but iomap only allows BIO_MAX_PAGES when creating the bio. And: > > > > #define BIO_MAX_PAGES 256 > > > > So even on a 64k page machine, we should not be building a bio with > > more than 16MB of data in it. So how are we getting 4GB of data into > > it? > > BIO_MAX_PAGES is the number of bio_vecs in the bio, it has no > direct implication on the size, as each entry can fit up to UINT_MAX > bytes. > 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? 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? Brian
