From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755608AbdDLVS7 (ORCPT ); Wed, 12 Apr 2017 17:18:59 -0400 Received: from mx2.suse.de ([195.135.220.15]:35636 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752851AbdDLVS4 (ORCPT ); Wed, 12 Apr 2017 17:18:56 -0400 Subject: Re: [RFC 2/6] mm, mempolicy: stop adjusting current->il_next in mpol_rebind_nodemask() To: Christoph Lameter References: <20170411140609.3787-1-vbabka@suse.cz> <20170411140609.3787-3-vbabka@suse.cz> <9665a022-197a-4b02-8813-66aca252f0f9@suse.cz> <97045760-77eb-c892-9bcb-daad10a1d91d@suse.cz> Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, Li Zefan , Michal Hocko , Mel Gorman , David Rientjes , Hugh Dickins , Andrea Arcangeli , Anshuman Khandual , "Kirill A. Shutemov" From: Vlastimil Babka Message-ID: Date: Wed, 12 Apr 2017 23:18:53 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12.4.2017 23:16, Christoph Lameter wrote: > On Wed, 12 Apr 2017, Vlastimil Babka wrote: > >>>> Well, interleave_nodes() will then potentially return a node outside of >>>> the allowed memory policy when its called for the first time after >>>> mpol_rebind_.. . But thenn it will find the next node within the >>>> nodemask and work correctly for the next invocations. >>> >>> Hmm, you're right. But that could be easily fixed if il_next became il_prev, so >>> we would return the result of next_node_in(il_prev) and also store it as the new >>> il_prev, right? I somehow assumed it already worked that way. > > Yup that makes sense and I thought about that when I saw the problem too. > >> @@ -863,6 +856,18 @@ static int lookup_node(unsigned long addr) >> return err; >> } >> >> +/* Do dynamic interleaving for a process */ >> +static unsigned interleave_nodes(struct mempolicy *policy, bool update_prev) > > Why do you need an additional flag? Would it not be better to always > update and switch the update_prev=false case to simply use > next_node_in()? Looked to me as better wrapping, but probably overengineered, ok. Will change for v2.