Thread (18 messages) 18 messages, 6 authors, 2017-10-30

Re: [PATCH 2/2] Add /proc/PID/{smaps, numa_maps} support for DAX

flat view

From: Dan Williams <hidden>
Date: 2017-10-26 15:56:11
Also in: lkml

On Thu, Oct 26, 2017 at 8:07 AM, Michal Hocko [off-list ref] wrote:
On Thu 26-10-17 07:51:20, Dave Hansen wrote:
quoted
On 10/26/2017 07:31 AM, Michal Hocko wrote:
quoted
On Thu 26-10-17 07:24:14, Dave Hansen wrote:
quoted
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.
That sounds like a very weak justification to adding new stuff to smaps
to be honest.
Yep, agreed.  It can't go in _just_ for DAX, and Fan and the other DAX
folks need to elaborate on their needs here.

Do you have any better ideas?  If we did this, we could probably make an
argument that the AnonHuge fields could go away some day.  They haven't
always been there.
Yeah, if there is an effective way to see large mappings within the
range then AnonHuge should probably go away. If that is possible due to
userspace regressions...
quoted
The only other alternative I can think of are truly DAX-specific
interfaces, which also seem like a really bad idea.
Well, if this is mostly for debugging purposes then why not?
I should have recalled this sooner, but for device-dax we don't need
smaps support because the mapping type is enforced by the device. I.e.
if you set the alignment to 2MB you are guaranteed to either get PMD
mappings or SIGBUS. Filesystem DAX is where things are more dynamic,
but because they are dynamic smaps is only an ephemeral answer.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help