linux-kernel - Re: [PATCH v7 0/5] Introduce multi-preference mempolicy

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] [day] [month] [year] [list]

Message-ID: <20211201053313.GB14778@shbuild999.sh.intel.com>
Date:   Wed, 1 Dec 2021 13:33:13 +0800
From:   Feng Tang <feng.tang@...el.com>
To:     ligang.bdlg@...edance.com
Cc:     linux-api@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, ben.widawsky@...el.com,
        dave.hansen@...ux.intel.com
Subject: Re: [PATCH v7 0/5] Introduce multi-preference mempolicy

Hi Gang,

On Wed, Dec 01, 2021 at 11:09:18AM +0800, Gang Li wrote:
> Hi Feng:
> 
> I am a little confused:
> We have `MPOL_PREFERRED`, why you introduce `MPOL_PREFERRED_MANY` instead of
> making `MPOL_PREFERRED` support multiple preferred nodes?

Cc Ben and Dave.

Actually in the end of this cover letter, there is some explaination
about it, qutoed here:

"
In v1, Andi Kleen brought up reusing MPOL_PREFERRED as the mode for the API.
There wasn't consensus around this, so I've left the existing API as it was. I'm
open to more feedback here, but my slight preference is to use a new API as it
ensures if people are using it, they are entirely aware of what they're doing
and not accidentally misusing the old interface. (In a similar way to how
MPOL_LOCAL was introduced).

In v1, Michal also brought up renaming this MPOL_PREFERRED_MASK. I'm equally
fine with that change, but I hadn't heard much emphatic support for one way or
another, so I've left that too.
"

Ben made this as he initiated the patchset, and I agree this can keep
the API consistent for user . Also at that time, there was another
factor that policy MPOL_PREFERRED and MPOL_LOCAL were coupled tightly
together. 

Thanks,
Feng