linux-kernel - Re: [PATCH 2/2] Add /proc/PID/{smaps, numa

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: <CAPcyv4jCPE4NRGH2MmbKWbNOSZe4feVDQmJwozJBTYMRg2uqjQ@mail.gmail.com>
Date:   Fri, 27 Oct 2017 03:31:46 -0700
From:   Dan Williams <dan.j.williams@...el.com>
To:     "Du, Fan" <fan.du@...el.com>
Cc:     "Hansen, Dave" <dave.hansen@...el.com>,
        Michal Hocko <mhocko@...nel.org>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "hch@....de" <hch@....de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-api@...r.kernel.org" <linux-api@...r.kernel.org>
Subject: Re: [PATCH 2/2] Add /proc/PID/{smaps, numa_maps} support for DAX

On Thu, Oct 26, 2017 at 9:00 PM, Du, Fan <fan.du@...el.com> wrote:
>
>
>>-----Original Message-----
>>From: linux-kernel-owner@...r.kernel.org
>>[mailto:linux-kernel-owner@...r.kernel.org] On Behalf Of Dave Hansen
>>Sent: Thursday, October 26, 2017 10:51 PM
>>To: Michal Hocko <mhocko@...nel.org>
>>Cc: Du, Fan <fan.du@...el.com>; akpm@...ux-foundation.org; hch@....de;
>>Williams, Dan J <dan.j.williams@...el.com>; linux-kernel@...r.kernel.org;
>>linux-api@...r.kernel.org
>>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?