Eliot Moss wrote: > A quick followup, which may indicate a flaw in fs_dax page mapping code. > > When doing that mapping of 32G, for each group of 8G, all but the last 2M > resulted in a NOPAGE 2M fault. The very last 2M chunk of each 8G region > resulted in FALLBACK. > > Then, a spawned thread accessed the same region sequentially, This caused > the upper 16G all to result in FALLBACK (except those two 2M regions that > already had done FALLBACK). > > The first case "smells" like some kind of range error in the code. > > The second one is also curiously regular, but I have less of a theory > about it. > > Is this the right place for discussion of this behavior and possible patches?
This is a good place to reach people that can poke at this, but may need to pull in fsdevel folks if this gets into a question about layout behaviour of a specific fs. Even the nvdimm unit tests have gone through changes where different kernels result in different file block allocation behaviour. For example: https://lkml.kernel.org/r/capcyv4g2u6yyj6bo_nmguypfe2d04pzvkp0jqwnamy9hz3u...@mail.gmail.com So my hesitation to jump in on this stems from this usually being something outside of what fs/dax.c can control.
