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.1 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,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 27B73C433E1 for ; Sun, 16 Aug 2020 22:57:03 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BBF9F206F4 for ; Sun, 16 Aug 2020 22:57:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Tozs28+Q" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BBF9F206F4 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 1866A6B0002; Sun, 16 Aug 2020 18:57:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 136FD6B0005; Sun, 16 Aug 2020 18:57:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F40796B0006; Sun, 16 Aug 2020 18:57:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0112.hostedemail.com [216.40.44.112]) by kanga.kvack.org (Postfix) with ESMTP id DF2A56B0002 for ; Sun, 16 Aug 2020 18:57:01 -0400 (EDT) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 963FD824556B for ; Sun, 16 Aug 2020 22:57:01 +0000 (UTC) X-FDA: 77157943842.21.trade92_4307f8427011 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin21.hostedemail.com (Postfix) with ESMTP id 63233180442F1 for ; Sun, 16 Aug 2020 22:57:01 +0000 (UTC) X-HE-Tag: trade92_4307f8427011 X-Filterd-Recvd-Size: 6577 Received: from mail-lj1-f193.google.com (mail-lj1-f193.google.com [209.85.208.193]) by imf11.hostedemail.com (Postfix) with ESMTP for ; Sun, 16 Aug 2020 22:57:00 +0000 (UTC) Received: by mail-lj1-f193.google.com with SMTP id w25so15395631ljo.12 for ; Sun, 16 Aug 2020 15:57:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=3ISqgAr5mVsqcVa5T/RQjHidddeXrpowXieFk+y0N8M=; b=Tozs28+Qr6u9Y2FikwR+jDpH9HiXrIZYuArZFgKGp6L+61g+WIW8akdKsM8pV6R5rf zPoM3Dqd71cnXwoXmfKE+pm/QJUO/9lbJgEaogX9I1++lIJu+Co37tPr/fYD6kcuZPXR HN49bkQ7vRNngQUZCBgEPszGRnQ5DhQtYTVc3qidPucZ/6sjdd3bYtNMMal5enKQoQov O/GxVyvlP0sI22J876DhcRauqgbPl2x5mFBZjxjr0l8zkguCWhFmj3jXZaDv3rBJteNC v5v0/pIbtWP0qCP4brtQ2Qidqk36Nip/rWFcFDmlm/SHpwNxXZqh+aoF3MPGZFIGjRrt zeEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=3ISqgAr5mVsqcVa5T/RQjHidddeXrpowXieFk+y0N8M=; b=r2pkJHepguWuQhdrStlz2jwTg7Fjyg+mliRkP6VE62/kJ29GsgDkyMsGJkFWjjFx2a f7SqQMtpvRHo+14SJnKncUIzjw+iXm4eG9vdjadrHem7CwlrIKbfbjTZ6kgfwJEltpA2 MSrLQ+GgZq020W8S+J5CztJZST30OtLhv0VDFdP2MzgKShu0yFFOVY5OpOrRSRUna7aL SeoFHaNgYIKhqHcYEi6lXTvdcYKnptb9PDSPMQyxIodhEC4CpJWvp2LF8MvnY52l00st La4LZzjWdBSf2AMtFZrQJvmHHsisB4vDoocag/GFM5FL9J0lWsfeo14WfjTInx3E9lcc /upQ== X-Gm-Message-State: AOAM530eXyUa6cJJLJC2IAnlVeL/YT+UMoEjApX+BaXjSn/lMWuyQFl9 hAO+W3LZ6Koud01mBBE/uLU= X-Google-Smtp-Source: ABdhPJygnaGyT1ZhEKzm7pUMmPKtXAXP6IeR+TsG4iwr2FYwxzI3Aop8J8fPG/+EY1xIjca9gaMHiA== X-Received: by 2002:a2e:9f46:: with SMTP id v6mr5755863ljk.66.1597618619303; Sun, 16 Aug 2020 15:56:59 -0700 (PDT) Received: from pc636 (h5ef52e31.seluork.dyn.perspektivbredband.net. [94.245.46.49]) by smtp.gmail.com with ESMTPSA id s1sm4634109lfi.76.2020.08.16.15.56.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 16 Aug 2020 15:56:57 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Mon, 17 Aug 2020 00:56:55 +0200 To: Peter Zijlstra , Michal Hocko Cc: "Paul E. McKenney" , Thomas Gleixner , Michal Hocko , Uladzislau Rezki , LKML , RCU , linux-mm@kvack.org, Andrew Morton , Vlastimil Babka , Matthew Wilcox , "Theodore Y . Ts'o" , Joel Fernandes , Sebastian Andrzej Siewior , Oleksiy Avramchenko Subject: Re: [RFC-PATCH 1/2] mm: Add __GFP_NO_LOCKS flag Message-ID: <20200816225655.GA17869@pc636> References: <20200813220619.GA2674@hirez.programming.kicks-ass.net> <875z9m3xo7.fsf@nanos.tec.linutronix.de> <20200814083037.GD3982@worktop.programming.kicks-ass.net> <20200814141425.GM4295@paulmck-ThinkPad-P72> <20200814161106.GA13853@paulmck-ThinkPad-P72> <20200814174924.GI3982@worktop.programming.kicks-ass.net> <20200814180224.GQ4295@paulmck-ThinkPad-P72> <875z9lkoo4.fsf@nanos.tec.linutronix.de> <20200814204140.GT4295@paulmck-ThinkPad-P72> <20200814215206.GL3982@worktop.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200814215206.GL3982@worktop.programming.kicks-ass.net> User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Queue-Id: 63233180442F1 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam05 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, Aug 14, 2020 at 11:52:06PM +0200, Peter Zijlstra wrote: > On Fri, Aug 14, 2020 at 01:41:40PM -0700, Paul E. McKenney wrote: > > > And that enforces the GFP_NOLOCK allocation mode or some other solution > > > unless you make a new rule that calling call_rcu() is forbidden while > > > holding zone lock or any other lock which might be nested inside the > > > GFP_NOWAIT zone::lock held region. > > > > Again, you are correct. Maybe the forecasted weekend heat will cause > > my brain to hallucinate a better solution, but in the meantime, the > > GFP_NOLOCK approach looks good from this end. > > So I hate __GFP_NO_LOCKS for a whole number of reasons: > > - it should be called __GFP_LOCKLESS if anything > - it sprinkles a bunch of ugly branches around the allocator fast path > - it only works for order==0 > I had a look at your proposal, that is below. An underlying logic stays almost the same as what has been proposed by this RFC. I mean i do not see any difference in your approach that does exactly the same - providing lock-less access to the per-cpu-lists. I am not talking about implementation details and farther improvements, like doing also a search over zonelist -> ZONE_NORMAL. Also, please note. The patch was tagged as RFC. > > Combined I really odn't think this should be a GFP flag. How about a > special purpose allocation function, something like so.. > I agree with you. Also i think, Michal, does not like the GFP flag, it introduces more complexity to the page allocator. So, providing lock-less access as a separate function is better approach, IMHO. Michal asked to provide some data regarding how many pages we need and how "lockless allocation" behaves when it comes to success vs failed scenarios. Please see below some results. The test case is a tight loop of 1 000 000 allocations doing kmalloc() and kfree_rcu(): sudo ./test_vmalloc.sh run_test_mask=2048 single_cpu_test=1 for (i = 0; i < 1 000 000; i++) { p = kmalloc(sizeof(*p), GFP_KERNEL); if (!p) return -1; p->array[0] = 'a'; kvfree_rcu(p, rcu); } wget ftp://vps418301.ovh.net/incoming/1000000_kmalloc_kfree_rcu_proc_percpu_pagelist_fractio_is_0.png wget ftp://vps418301.ovh.net/incoming/1000000_kmalloc_kfree_rcu_proc_percpu_pagelist_fractio_is_8.png Also i would like to underline, that kfree_rcu() reclaim logic can be improved further, making the drain logic more efficient when it comes to time, thus to reduce a footprint as a result number of required pages. -- Vlad Rezki