From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753982AbdGNLAa (ORCPT ); Fri, 14 Jul 2017 07:00:30 -0400 Received: from mx2.suse.de ([195.135.220.15]:34403 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753890AbdGNLA2 (ORCPT ); Fri, 14 Jul 2017 07:00:28 -0400 Date: Fri, 14 Jul 2017 13:00:25 +0200 From: Michal Hocko To: Mel Gorman Cc: linux-mm@kvack.org, Andrew Morton , Johannes Weiner , Vlastimil Babka , LKML Subject: Re: [PATCH 7/9] mm, page_alloc: remove stop_machine from build_all_zonelists Message-ID: <20170714110025.GG2618@dhcp22.suse.cz> References: <20170714080006.7250-1-mhocko@kernel.org> <20170714080006.7250-8-mhocko@kernel.org> <20170714095932.jihl6h3y77hxyyiu@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170714095932.jihl6h3y77hxyyiu@suse.de> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri 14-07-17 10:59:32, Mel Gorman wrote: > On Fri, Jul 14, 2017 at 10:00:04AM +0200, Michal Hocko wrote: > > From: Michal Hocko > > > > build_all_zonelists has been (ab)using stop_machine to make sure that > > zonelists do not change while somebody is looking at them. This is > > is just a gross hack because a) it complicates the context from which > > we can call build_all_zonelists (see 3f906ba23689 ("mm/memory-hotplug: > > switch locking to a percpu rwsem")) and b) is is not really necessary > > especially after "mm, page_alloc: simplify zonelist initialization". > > > > Updates of the zonelists happen very seldom, basically only when a zone > > becomes populated during memory online or when it loses all the memory > > during offline. A racing iteration over zonelists could either miss a > > zone or try to work on one zone twice. Both of these are something we > > can live with occasionally because there will always be at least one > > zone visible so we are not likely to fail allocation too easily for > > example. > > > > Signed-off-by: Michal Hocko > > This patch is contingent on the last patch which updates in place > instead of zeroing the early part of the zonelist first but needs to fix > the stack usage issues. I think it's also worth pointing out in the > changelog that stop_machine never gave the guarantees it claimed as a > process iterating through the zonelist can be stopped so when it resumes > the zonelist has changed underneath it. Doing it online is roughly > equivalent in terms of safety. OK, what about the following addendum? " Please note that the original stop_machine approach doesn't really provide a better exclusion because the iteration might be interrupted half way (unless the whole iteration is preempt disabled which is not the case in most cases) so the some zones could still be seen twice or a zone missed. " -- Michal Hocko SUSE Labs From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f70.google.com (mail-wm0-f70.google.com [74.125.82.70]) by kanga.kvack.org (Postfix) with ESMTP id E06D3440905 for ; Fri, 14 Jul 2017 07:00:28 -0400 (EDT) Received: by mail-wm0-f70.google.com with SMTP id b189so8665028wmb.12 for ; Fri, 14 Jul 2017 04:00:28 -0700 (PDT) Received: from mx1.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id 84si1959976wmb.86.2017.07.14.04.00.27 for (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 14 Jul 2017 04:00:27 -0700 (PDT) Date: Fri, 14 Jul 2017 13:00:25 +0200 From: Michal Hocko Subject: Re: [PATCH 7/9] mm, page_alloc: remove stop_machine from build_all_zonelists Message-ID: <20170714110025.GG2618@dhcp22.suse.cz> References: <20170714080006.7250-1-mhocko@kernel.org> <20170714080006.7250-8-mhocko@kernel.org> <20170714095932.jihl6h3y77hxyyiu@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170714095932.jihl6h3y77hxyyiu@suse.de> Sender: owner-linux-mm@kvack.org List-ID: To: Mel Gorman Cc: linux-mm@kvack.org, Andrew Morton , Johannes Weiner , Vlastimil Babka , LKML On Fri 14-07-17 10:59:32, Mel Gorman wrote: > On Fri, Jul 14, 2017 at 10:00:04AM +0200, Michal Hocko wrote: > > From: Michal Hocko > > > > build_all_zonelists has been (ab)using stop_machine to make sure that > > zonelists do not change while somebody is looking at them. This is > > is just a gross hack because a) it complicates the context from which > > we can call build_all_zonelists (see 3f906ba23689 ("mm/memory-hotplug: > > switch locking to a percpu rwsem")) and b) is is not really necessary > > especially after "mm, page_alloc: simplify zonelist initialization". > > > > Updates of the zonelists happen very seldom, basically only when a zone > > becomes populated during memory online or when it loses all the memory > > during offline. A racing iteration over zonelists could either miss a > > zone or try to work on one zone twice. Both of these are something we > > can live with occasionally because there will always be at least one > > zone visible so we are not likely to fail allocation too easily for > > example. > > > > Signed-off-by: Michal Hocko > > This patch is contingent on the last patch which updates in place > instead of zeroing the early part of the zonelist first but needs to fix > the stack usage issues. I think it's also worth pointing out in the > changelog that stop_machine never gave the guarantees it claimed as a > process iterating through the zonelist can be stopped so when it resumes > the zonelist has changed underneath it. Doing it online is roughly > equivalent in terms of safety. OK, what about the following addendum? " Please note that the original stop_machine approach doesn't really provide a better exclusion because the iteration might be interrupted half way (unless the whole iteration is preempt disabled which is not the case in most cases) so the some zones could still be seen twice or a zone missed. " -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org