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]

Date:   Fri, 27 Oct 2017 10:42:33 +0200
From:   Michal Hocko <mhocko@...nel.org>
To:     "Du, Fan" <fan.du@...el.com>
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>
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.
-- 
Michal Hocko
SUSE Labs