On Thu, Oct 26, 2017 at 9:00 PM, Du, Fan <fan.du@xxxxxxxxx> wrote: > > >>-----Original Message----- >>From: linux-kernel-owner@xxxxxxxxxxxxxxx >>[mailto:linux-kernel-owner@xxxxxxxxxxxxxxx] On Behalf Of Dave Hansen >>Sent: Thursday, October 26, 2017 10:51 PM >>To: Michal Hocko <mhocko@xxxxxxxxxx> >>Cc: Du, Fan <fan.du@xxxxxxxxx>; akpm@xxxxxxxxxxxxxxxxxxxx; hch@xxxxxx; >>Williams, Dan J <dan.j.williams@xxxxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx; >>linux-api@xxxxxxxxxxxxxxx >>Subject: Re: [PATCH 2/2] Add /proc/PID/{smaps, numa_maps} support for DAX >> >>On 10/26/2017 07:31 AM, Michal Hocko wrote: >>> On Thu 26-10-17 07:24:14, Dave Hansen wrote: >>>> 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? -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
