Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp1172590pxk; Fri, 2 Oct 2020 03:01:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzLb5PMkZe7maur586VWJ4xc6pUd8f4im6Fg27y6uk/9O3oFRd2iG3LhGrCRm3tKn+nogZl X-Received: by 2002:a50:d94d:: with SMTP id u13mr1390620edj.365.1601632897678; Fri, 02 Oct 2020 03:01:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601632897; cv=none; d=google.com; s=arc-20160816; b=QCveDOu32O6RPanNJWCeiEV5RpZSM80WErhE8jxDrZvbSd0BBAYZWfVuBghLAu8L4r +s/f9Zb0WNocbDZoh6Yd1y9bkDAf5FlL2qA29QrdqHpSgbhFj0y9T/qF1LO220BC1O3b W2GgSUlTWfCTBjefbnEebrA/BnAVh7qaTstKtKwPHtX/ADmXBQm/pYs2uPvh6SZptd8F WHz4p66uY/w8YODLDKSlJhJwvJQDMDosrHsi9icJvoR1TYP4wlsrNUEYb5ajTh01wPa0 wqfRdTF22yFU4Y83xCjCDF2Fx2JP6nVsvzyRe2QmWZs2SOcSHKi8hB7xnxd945sq/z2j lvOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=+qVSAF9QF5Wn9XzbJ1v3TpJKGzqIp+0Y4N7lccEcZNY=; b=lXu7j6oqo35+Qt1JyDeqqrjrta6i6g1XcF1CWZIdxE1BqyBJQ3hw8BDFRUj8a/sZH0 zm63FNq/AleRIuPu8U/1Qai2pY2N///P5cgIiOOW7Xkh/e0wEJrX79MbOjVfsxqgZ+OG qfqBzFMCBQ7Gt6SojZOh9r+bqCoRgE2c70evQ8v83x7Z/Ng77rUUVZ4souUPsvfBh4b4 FHhNYaiWn07SCQxmw8SHmmPsSPkXSsMHtDvIcSWiE13EiLRpJUytT3IqXGG8wLexigxy l1mfDJfAKiuJgMy2BHbeFbKsffnmx0ZNg7nmPDhR/Z5GB8Y98l7mSdg50TCY1oN+7cSD J+uQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b="XHqr/9rV"; 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 f16si708529ejt.311.2020.10.02.03.01.14; Fri, 02 Oct 2020 03:01:37 -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; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b="XHqr/9rV"; 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 S2387692AbgJBJ7L (ORCPT + 99 others); Fri, 2 Oct 2020 05:59:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41208 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725993AbgJBJ7L (ORCPT ); Fri, 2 Oct 2020 05:59:11 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DB0EAC0613D0; Fri, 2 Oct 2020 02:59:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=+qVSAF9QF5Wn9XzbJ1v3TpJKGzqIp+0Y4N7lccEcZNY=; b=XHqr/9rV2rJsIThsPn5As2WrRz DVEa6LNlad/o7oLyeoPINbVx5XiLg3zZ3m1XWtcClNhcLvTWy0APIzcsBtw5d27ZW8zyfq/XuPb9v ToeTTQ+wCLfaMZI6BPRq/VrzM3A13+fYruZhSfSnu+SnRdNNKy8H+drvT6SQfoZtX+vEF3IQ+6qfG QiMa8wbdyrnwhCLcR0gF2U8wj6hXZ28KZY1Z3v/FkIAcWmqEGQFggUOEXMHrZa2S2VRaNUGE5ZSzp snqh3Ii4ECojsW0oNGEc1kbbnJGLNPBxXL0BdXkt10RyakDC17iAS99h9l2KW7oYitYhJ63gBqjAu +Pn6bkZA==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.92.3 #3 (Red Hat Linux)) id 1kOHq7-0002BC-OL; Fri, 02 Oct 2020 09:59:00 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 8DDD23006D0; Fri, 2 Oct 2020 11:58:58 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 7BF0920839A41; Fri, 2 Oct 2020 11:58:58 +0200 (CEST) Date: Fri, 2 Oct 2020 11:58:58 +0200 From: Peter Zijlstra To: Mel Gorman 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: <20201002095858.GN2611@hirez.programming.kicks-ass.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> <20201002094502.GD3227@techsingularity.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201002094502.GD3227@techsingularity.net> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 02, 2020 at 10:45:02AM +0100, Mel Gorman wrote: > 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. Not exporting it for modules helps, but yes. > > > > 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. Oh quite agreed, aka death by accounting. But if people are enabling DEBUG options in production kernels, there's something wrong, no? Should we now go add CONFIG_REALLY_DEBUG_STAY_AWAY_ALREADY options?