Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Thu, 7 Oct 2021 11:25:10 +0100
From:   Mel Gorman <mgorman@suse.de>
To:     Bharata B Rao <bharata@amd.com>
Cc:     linux-kernel@vger.kernel.org, mingo@redhat.com,
        peterz@infradead.org
Subject: Re: [RFC PATCH 4/4] sched/numa: Don't update mm->numa_next_scan from
 fault path
Message-ID: <20211007102510.GQ3891@suse.de>
References: <20211004105706.3669-1-bharata@amd.com>
 <20211004105706.3669-5-bharata@amd.com>
 <20211005082335.GN3891@suse.de>
 <dbb74941-4d6c-3e5a-2f5c-d18001c2856c@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: inline
In-Reply-To: <dbb74941-4d6c-3e5a-2f5c-d18001c2856c@amd.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

On Tue, Oct 05, 2021 at 02:40:15PM +0530, Bharata B Rao wrote:
> > 
> > Updating via cmpxchg would be ok to avoid potential collisions between
> > threads updating a shared mm.
> 
> Ok, may be I could just resend with changing the scan period update
> to use cmpxchg.
> 
> I also notice that in this case of scan period update, we just return
> without resetting the p->numa_faults_locality[]. Do you think if
> skipping the reset doesn't matter in this case?
> 

If there is no fault activity or migrations are failing, there is no
advantage to clearing numa_faults_locality[]. The information there
is still useful even if the scan period is updated.

-- 
Mel Gorman
SUSE Labs