Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp1166461pxk; Fri, 2 Oct 2020 02:49:21 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz2PR8betjqDch1277VYd2p8o3rP1yMz8t78BXLZEbNZmA4LG2XmeU/B7iGBEm6qZOT8q9a X-Received: by 2002:a17:906:4a53:: with SMTP id a19mr1479452ejv.56.1601632161452; Fri, 02 Oct 2020 02:49:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601632161; cv=none; d=google.com; s=arc-20160816; b=abanPiMeqLybgdyS/lmvV4Tb97PIpCz2fr6OkyhiwQt8ZajKR9kObSaviePA+jNY2K 27i6EuG6+Gr77srKYFUbP+/7MqAg/okgCIwtocoBbExzcv/NEs2nH27+RdnsfKWtkL2o 3W7c8x7iDqEiAfKSccMroPnBqTVxAby14bccoVm6BiLoJ2iajLRKG3MC5GJGHPA2l7vr Rc7dhbCRq4WFW4JOvzlMClpnTaFiYfx9VelmerIoJQSlKIzme9nlnnJx8m0gihJWRLTK UgiV7/CKpTkomszBXvmXOUi+tNHe2znCe0+7MtWyscnbes/g9Xn121iVjtm/Aw1a8hb0 DCDQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=niaEqDn2ect9GvnvjcJqesPF9cmwKNTfHvgGbGbG2Ak=; b=uLwUdSGj1lYl+y7mOCfQX2qmFRPeNQD7ZFymo0k8s3Nn0FI7xKKuEj0F2R6bziMaMx phi7h4fIHUC8Dduh+/xSyk9WvDE5GttTn/2KSleFydXINIaNoVsVlPM76Md+kr1N3Lrp GHfQV8k22Y+fqVPvMsZDKmhVQYrSUAE55m/p6sRGcC+bmRx4aNP1Po/CWhghX8aYt//H 2avlkpXyP19eCcWIXzTnojLdz9uT8TqaUronCLPiKH4aGgbCaCKc0Dd/I8hKu8eWkoEH vKCVAAJHxbmNxTM8jTKi+6oFelLZszBiwmQ5aEwqe3cvUYtNpbxaPI0at2P4SwrwUSZm PWhQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r15si697182ejx.326.2020.10.02.02.48.58; Fri, 02 Oct 2020 02:49:21 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387680AbgJBJpF (ORCPT + 99 others); Fri, 2 Oct 2020 05:45:05 -0400 Received: from outbound-smtp38.blacknight.com ([46.22.139.221]:35487 "EHLO outbound-smtp38.blacknight.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725993AbgJBJpF (ORCPT ); Fri, 2 Oct 2020 05:45:05 -0400 Received: from mail.blacknight.com (pemlinmail06.blacknight.ie [81.17.255.152]) by outbound-smtp38.blacknight.com (Postfix) with ESMTPS id CF531194D for ; Fri, 2 Oct 2020 10:45:03 +0100 (IST) Received: (qmail 29917 invoked from network); 2 Oct 2020 09:45:03 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.22.4]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 2 Oct 2020 09:45:03 -0000 Date: Fri, 2 Oct 2020 10:45:02 +0100 From: Mel Gorman To: Peter Zijlstra Cc: Michal Hocko , Uladzislau Rezki , Vlastimil Babka , LKML , RCU , linux-mm@kvack.org, Andrew Morton , "Paul E . McKenney" , Thomas Gleixner , "Theodore Y . Ts'o" , Joel Fernandes , Sebastian Andrzej Siewior , Oleksiy Avramchenko Subject: Re: [RFC-PATCH 2/4] mm: Add __rcu_alloc_page_lockless() func. Message-ID: <20201002094502.GD3227@techsingularity.net> References: <20200918194817.48921-1-urezki@gmail.com> <20200918194817.48921-3-urezki@gmail.com> <38f42ca1-ffcd-04a6-bf11-618deffa897a@suse.cz> <20200929220742.GB8768@pc636> <795d6aea-1846-6e08-ac1b-dbff82dd7133@suse.cz> <20201001192626.GA29606@pc636> <20201002071123.GB20872@dhcp22.suse.cz> <20201002085014.GC3227@techsingularity.net> <20201002090729.GU2628@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20201002090729.GU2628@hirez.programming.kicks-ass.net> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 02, 2020 at 11:07:29AM +0200, Peter Zijlstra wrote: > On Fri, Oct 02, 2020 at 09:50:14AM +0100, Mel Gorman wrote: > > On Fri, Oct 02, 2020 at 09:11:23AM +0200, Michal Hocko wrote: > > > > > +#define ___GFP_NO_LOCKS 0x800000u > > > > > > Even if a new gfp flag gains a sufficient traction and support I am > > > _strongly_ opposed against consuming another flag for that. Bit space is > > > limited. > > > > That is definitely true. I'm not happy with the GFP flag at all, the > > comment is at best a damage limiting move. It still would be better for > > a memory pool to be reserved and sized for critical allocations. > > This is one of the reasons I did a separate allocation function. No GFP > flag to leak into general usage. > Even a specific function with a hint that "this is for RCU only" will not prevent abuse. > > > Besides that we certainly do not want to allow craziness like > > > __GFP_NO_LOCK | __GFP_RECLAIM (and similar), do we? > > > > That would deserve to be taken to a dumpster and set on fire. The flag > > combination could be checked in the allocator but the allocator path fast > > paths are bad enough already. > > Isn't that what we have CONFIG_DEBUG_VM for? It's enabled by default by enough distros that adding too many checks is potentially painful. Granted it would be missed by most benchmarking which tend to control allocations from userspace but a lot of performance problems I see are the "death by a thousand cuts" variety. -- Mel Gorman SUSE Labs