Messages in this thread | | | From | "Huang\, Ying" <> | Subject | Re: [PATCH -V2 2/2] autonuma: Migrate on fault among multiple bound nodes | Date | Wed, 11 Nov 2020 14:50:07 +0800 |
| |
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
| |