From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752740AbdARKPH (ORCPT ); Wed, 18 Jan 2017 05:15:07 -0500 Received: from mx2.suse.de ([195.135.220.15]:42623 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752684AbdARKNz (ORCPT ); Wed, 18 Jan 2017 05:13:55 -0500 Date: Wed, 18 Jan 2017 10:55:50 +0100 From: Michal Hocko To: Vlastimil Babka Cc: Mel Gorman , Ganapatrao Kulkarni , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [RFC 3/4] mm, page_alloc: move cpuset seqcount checking to slowpath Message-ID: <20170118095549.GM7015@dhcp22.suse.cz> References: <20170117221610.22505-1-vbabka@suse.cz> <20170117221610.22505-4-vbabka@suse.cz> <20170118094054.GJ7015@dhcp22.suse.cz> <7b984dde-78c5-2efc-daef-bcdcc51fc9cb@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7b984dde-78c5-2efc-daef-bcdcc51fc9cb@suse.cz> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 18-01-17 10:48:55, Vlastimil Babka wrote: > On 01/18/2017 10:40 AM, Michal Hocko wrote: > > On Tue 17-01-17 23:16:09, Vlastimil Babka wrote: > > > This is a preparation for the following patch to make review simpler. While > > > the primary motivation is a bug fix, this could also save some cycles in the > > > fast path. > > > > I cannot say I would be happy about this patch :/ The code is still very > > confusing and subtle. I really think we should get rid of > > synchronization with the concurrent cpuset/mempolicy updates instead. > > Have you considered that instead? > > Not so thoroughly yet, but I already suspect it would be intrusive for > stable. We could make copies of nodemask and mems_allowed and protect just > the copying with seqcount, but that would mean overhead and stack space. > Also we might try revert 682a3385e773 ("mm, page_alloc: inline the fast path > of the zonelist iterator") ... If reverting that patch makes the problem go away and it is applicable for the stable I would rather go that way for stable and take a deep breath and rethink the whole cpuset and nodemask manipulation in the allocation path for a better long term solution. -- Michal Hocko SUSE Labs