On 1/5/2023 11:58 AM, Dan Williams wrote:
Eliot Moss wrote:
The configuration guidance for nvdimm indicates that fsdax mode requires 64
byte of metadata per 4K bytes of nvdimm. The map= command line argument can
be used to control whether that metadata is stored in the nvdimm or regular
(presumably DRAM) memory. We were pondering this as wonder what the metadata
is used for. I am thinking someone on this list can clarify. Thanks!
sizeof(struct page) == 64 (in most cases)
'struct page' is the object that describes the state of physical memory
pages to the rest of the kernel. Matthew wrote a useful summary of
'struct page' here:
https://blogs.oracle.com/linux/post/struct-page-the-linux-physical-page-frame-data-structure
Excellent coverage - makes sense! Thank you, Dan.
Eliot Moss
PS: Concerning that huge pages mapping question from a while back, is there an
fsdax group / list to which I could post that for followup? Thanks - EM
The 'fsdax' topic ties together linux...@kvack.org,
linux-fsde...@vger.kernel.org, and nvdimm@lists.linux.dev. So it depends
on what aspect you're digging into. When in doubt you can start here on
nvdimm@lists.linux.dev and folks here can help route. IIRC you had a
question about storage allocation alignment and huge mappings? I forgot
the details of the questionover the holiday break.
The issue is this. When mapping a large region, fsdax will *mostly* use
2Mb pages. It won't use 1Gb pages at all (that would be an enhancement
request, I suppose), but it strangely decided to do certain 2Mb regions
(which *could* be mapped with a 2Mb huge page) using 4Kb pages. A
possible clue is that when first mapping the region, it is the *last*
2Mb region that gets split into 4Kb pages. This suggests some kind of
boundary condition not being handled in the desired way (though the
result still *works*, just with more TLB miss overhead).
Sounds like re-posting the original query to linux-mm and linux-fsdevel
might be appropriate since it has to do with mmaping files on fsdax
file systems.
Best - Eliot
