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: <20170130185213.GA7198@redhat.com>
Date:   Mon, 30 Jan 2017 13:52:14 -0500
From:   Jerome Glisse <jglisse@...hat.com>
To:     Anshuman Khandual <khandual@...ux.vnet.ibm.com>
Cc:     linux-kernel@...r.kernel.org, linux-mm@...ck.org, mhocko@...e.com,
        vbabka@...e.cz, mgorman@...e.de, minchan@...nel.org,
        aneesh.kumar@...ux.vnet.ibm.com, bsingharora@...il.com,
        srikar@...ux.vnet.ibm.com, haren@...ux.vnet.ibm.com,
        dave.hansen@...el.com, dan.j.williams@...el.com
Subject: Re: [RFC V2 08/12] mm: Add new VMA flag VM_CDM

On Mon, Jan 30, 2017 at 09:05:49AM +0530, Anshuman Khandual wrote:
> VMA which contains CDM memory pages should be marked with new VM_CDM flag.
> These VMAs need to be identified in various core kernel paths for special
> handling and this flag will help in their identification.
> 
> Signed-off-by: Anshuman Khandual <khandual@...ux.vnet.ibm.com>


Why doing this on vma basis ? Why not special casing all those path on page
basis ?

After all you can have a big vma with some pages in it being cdm and other
being regular page. The CPU process might migrate to different CPU in a
different node and you might still want to have the regular page to migrate
to this new node and keep the cdm page while the device is still working
on them.

This is just an example, same can apply for ksm or any other kernel feature
you want to special case. Maybe we can store a set of flag in node that
tells what is allowed for page in node (ksm, hugetlb, migrate, numa, ...).

This would be more flexible and the policy choice can be left to each of
the device driver.

Cheers,
Jérôme

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ