Re: [PATCH -V2 2/2] autonuma: Migrate on fault among multiple bound nodes

["Huang\, Ying" <ying.huang@intel.com>]

Hi, Mel,

Mel Gorman <mgorman@suse.de> writes:

> On Wed, Nov 04, 2020 at 01:36:58PM +0800, Huang, Ying wrote:
>> > I've no specific objection to the patch or the name change. I can't
>> > remember exactly why I picked the name, it was 8 years ago but I think it
>> > was because the policy represented the most basic possible approach that
>> > could be done without any attempt at being intelligent and established
>> > a baseline. The intent was that anything built on top had to be better
>> > than the most basic policy imaginable. The name reflected the dictionary
>> > definition at the time and happened to match the acronym closely enough
>> > and I wanted to make it absolutely clear to reviewers that the policy
>> > was not good enough (ruling out MPOL_BASIC or variants thereof) even if
>> > it happened to work for some workload and there was no intent to report
>> > it to the userspace API.
>> >
>> > The only hazard with the patch is that applications that use MPOL_BIND
>> > on multiple nodes may now incur some NUMA balancing overhead due to
>> > trapping faults and migrations.
>> 
>> For this specific version of patch, I don't think this will happen.
>> Because now, MPOL_F_MOF need to be set in struct mempolicy, for
>> MPOL_BIND, only if mbind() syscall is called with MPOL_MF_LAZY, that
>> will be the case.  So I think most workloads will not be affected by
>> this patch.  The feature is opt-in.
>> 
>
> Ok.

I just found MPOL_MF_LAZY is disabled now.  And as in commit
a720094ded8c ("mm: mempolicy: Hide MPOL_NOOP and MPOL_MF_LAZY from
userspace for now"), the ABI needs to be revisted before exporting to
the user space formally.  Sorry about that, I should have found that
earlier.

Think about that.  I think MPOL_MF_LAZY is tied with MPOL_MF_MOVE, so
it's semantics isn't good for the purpose of the patch.  So I have
rewritten the patch and the description and sent it as follows, can you
help to review it?

https://lore.kernel.org/lkml/20201111063717.186589-1-ying.huang@intel.com/

Best Regards,
Huang, Ying