lkml.org 
[lkml]   [2017]   [Oct]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 2/2] Add /proc/PID/{smaps, numa_maps} support for DAX
From
Date
On 10/26/2017 07:16 AM, Michal Hocko wrote:
>> The original motivation was for DAX. They have parallel large page
>> infrastructure separate from hugetlbfs and THP. Their constraints about
>> when they can use large pages differ from the normal mm cases, so it is
>> hard to tell when large pages are in use. For instance, the file on
>> *disk* has to be 2MB contiguous and aligned to map with 2MB pages even
>> if the mmap() address is >2MB and 2MB-aligned.
>
> I assume there is some tool which is going to use this information?

Actually, I don't remember whether it was tooling or just confused
humans. I *think* Dan was trying to write test cases for huge page DAX
support and couldn't figure out whether or not it was using large pages.

>> But, in general, this seems like the thing that we probably should have
>> done in the first place for THP. It's a lot more generic and does not
>> require someone reading the file to know what the particular
>> architecture's page sizes are.
>
> I fully agree. This just shows how single usecase focus driven smaps
> file was. That is why I am asking about usecases when somebody want to
> try yet another special field there. Smaps has become a dump of of
> special cases which is not really easy to understand and so people tend
> to use it incorrectly.

We just have to be careful not to cram use-cases into the existing
fields which might make them meaningless. I fear that Fan Du's latest
patches do that.

\
 
 \ /
  Last update: 2017-10-26 16:24    [W:0.081 / U:0.800 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site