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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5A90DA2E42F8AE43BC4A093BF06788481AA517B6@SHSMSX104.ccr.corp.intel.com>
Date:   Fri, 27 Oct 2017 08:24:07 +0000
From:   "Du, Fan" <fan.du@...el.com>
To:     Michal Hocko <mhocko@...nel.org>
CC:     "Hansen, Dave" <dave.hansen@...el.com>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "hch@....de" <hch@....de>,
        "Williams, Dan J" <dan.j.williams@...el.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Du, Fan" <fan.du@...el.com>
Subject: RE: [PATCH v4] Add /proc/PID/smaps support for DAX



>-----Original Message-----
>From: Michal Hocko [mailto:mhocko@...nel.org]
>Sent: Friday, October 27, 2017 4:08 PM
>To: Du, Fan <fan.du@...el.com>
>Cc: Hansen, Dave <dave.hansen@...el.com>; akpm@...ux-foundation.org;
>hch@....de; Williams, Dan J <dan.j.williams@...el.com>;
>linux-kernel@...r.kernel.org
>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@...el.com>; akpm@...ux-foundation.org; hch@....de;
>> >Williams, Dan J <dan.j.williams@...el.com>; mhocko@...nel.org
>> >Cc: linux-kernel@...r.kernel.org
>> >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