From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9177CC41604 for ; Sun, 4 Oct 2020 01:34:22 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1D4902067C for ; Sun, 4 Oct 2020 01:34:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1D4902067C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=techsingularity.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 2F5886B005D; Sat, 3 Oct 2020 21:34:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 27F596B0062; Sat, 3 Oct 2020 21:34:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 147018E0001; Sat, 3 Oct 2020 21:34:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0168.hostedemail.com [216.40.44.168]) by kanga.kvack.org (Postfix) with ESMTP id D91C36B005D for ; Sat, 3 Oct 2020 21:34:20 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 58FF0180AD806 for ; Sun, 4 Oct 2020 01:34:20 +0000 (UTC) X-FDA: 77332522680.11.hate28_170f861271b1 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin11.hostedemail.com (Postfix) with ESMTP id 32309180F8B80 for ; Sun, 4 Oct 2020 01:34:20 +0000 (UTC) X-HE-Tag: hate28_170f861271b1 X-Filterd-Recvd-Size: 3648 Received: from outbound-smtp45.blacknight.com (outbound-smtp45.blacknight.com [46.22.136.57]) by imf33.hostedemail.com (Postfix) with ESMTP for ; Sun, 4 Oct 2020 01:34:19 +0000 (UTC) Received: from mail.blacknight.com (pemlinmail06.blacknight.ie [81.17.255.152]) by outbound-smtp45.blacknight.com (Postfix) with ESMTPS id D0571FA8CA 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) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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