[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5A90DA2E42F8AE43BC4A093BF06788481AA5198B@SHSMSX104.ccr.corp.intel.com>
Date: Fri, 27 Oct 2017 09:34:56 +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:43 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 08:24:07, Du, Fan wrote:
>>
>>
>> >-----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.
>
>I am not deeply familiar with DAX but I would expect that most users
>will use a FS on top of it where we have standard tools. If the use is
>direct then I can see how this make things more complicated but smaps is
>not the right answer IMHO. Why? Well, just consider that you map the
>same portions of the device multiple times for whatever reason and you
>are screwed because you have no means to distinguish those. So you will
>get bogus numbers. Or am I misunderstanding something?
>
>If you need a DAX device statistics then make them device specific. This
>is the only reliable way to get valid data.
Thanks for your comments, I will try to discuss with Dan about this.
Have a nice day!
>--
>Michal Hocko
>SUSE Labs
Powered by blists - more mailing lists