RE: [PATCH v4] Add /proc/PID/smaps support for DAX

[Du, Fan]

>-----Original Message-----
>From: Michal Hocko [mailto:mhocko@xxxxxxxxxx]
>Sent: Friday, October 27, 2017 4:08 PM
>To: Du, Fan <fan.du@xxxxxxxxx>
>Cc: Hansen, Dave <dave.hansen@xxxxxxxxx>; akpm@xxxxxxxxxxxxxxxxxxxx;
>hch@xxxxxx; Williams, Dan J <dan.j.williams@xxxxxxxxx>;
>linux-kernel@xxxxxxxxxxxxxxx
>Subject: Re: [PATCH v4] Add /proc/PID/smaps support for DAX
>
>On Fri 27-10-17 02:47:43, Du, Fan wrote:
>>
>>
>> >-----Original Message-----
>> >From: Hansen, Dave
>> >Sent: Thursday, October 26, 2017 10:03 PM
>> >To: Du, Fan <fan.du@xxxxxxxxx>; akpm@xxxxxxxxxxxxxxxxxxxx; hch@xxxxxx;
>> >Williams, Dan J <dan.j.williams@xxxxxxxxx>; mhocko@xxxxxxxxxx
>> >Cc: linux-kernel@xxxxxxxxxxxxxxx
>> >Subject: Re: [PATCH v4] Add /proc/PID/smaps support for DAX
>> >
>> >I'm honestly not understanding what problem this solves.  Could you,
>> >perhaps, do a before and after of smaps with and without this patch?
>>
>> The motivation here is described in the commit message.
>> ------------------------------------------------------------------------------------------
>> Memory behind device DAX is not attached into normal memory
>> management system, when user mmap /dev/dax, smaps part is
>> currently missing, so no idea for user to check how much
>> device DAX memory are actually used in practice.
>
>This might be motivation but you are still not explaining _why_ that is
>a problem. _Who_ is going to use that information and for _what_
>purpose. This is really essential!

If user created device DAX, how did one know how much memory being used?
by "used" I mean, page table mapping created, fact is no way to find out here.

why does this master? The answer is same as I bought 512G SSD disk, why
do I want to check disk usage with `df`?! if application use only 128G, it makes
no sense at all for me to buy more redundant persistent memory if Cloud provider
has more other option to choose.

Who cares the answers here? 
People who pays the money for persistent memory.


>Michal Hocko
>SUSE Labs