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-27 10:31:51
Also in: lkml

On Thu, Oct 26, 2017 at 9:00 PM, Du, Fan [off-list ref] wrote:
quoted
-----Original Message-----
From: linux-kernel-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
[mailto:linux-kernel-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org] On Behalf Of Dave Hansen
Sent: Thursday, October 26, 2017 10:51 PM
To: Michal Hocko <redacted>
Cc: Du, Fan <redacted>; akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org; hch-jcswGhMUV9g@public.gmane.org;
Williams, Dan J [off-list ref]; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 2/2] Add /proc/PID/{smaps, numa_maps} support for DAX

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.
If user creates device DAX /dev/dax with some capacity like 512G, mmap it and
Use it will, or touched 128G. To my best knowledge at this part, there is no
statistics reported how much memory behind DAX actually used.

This is the problem our customer is facing right now.
I'm not sure I understand, DAX is statically allocated. There's no
private memory taken from the page allocator to back device-dax
mappings. Unless you are trying to determine memory usage of page
tables?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help