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.6 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, 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 D459EC433E0 for ; Tue, 4 Aug 2020 21:04:55 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6FACB2086A for ; Tue, 4 Aug 2020 21:04:55 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="ijxV/DAh" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6FACB2086A 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 A61AA6B0003; Tue, 4 Aug 2020 17:04:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A12DB6B0005; Tue, 4 Aug 2020 17:04:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9012F6B0006; Tue, 4 Aug 2020 17:04:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0158.hostedemail.com [216.40.44.158]) by kanga.kvack.org (Postfix) with ESMTP id 7ACEF6B0003 for ; Tue, 4 Aug 2020 17:04:54 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 368DF3626 for ; Tue, 4 Aug 2020 21:04:54 +0000 (UTC) X-FDA: 77114115708.03.birds24_150d7af26fa9 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin03.hostedemail.com (Postfix) with ESMTP id DE0BF28A4EA for ; Tue, 4 Aug 2020 21:04:53 +0000 (UTC) X-HE-Tag: birds24_150d7af26fa9 X-Filterd-Recvd-Size: 6858 Received: from mail-lf1-f68.google.com (mail-lf1-f68.google.com [209.85.167.68]) by imf41.hostedemail.com (Postfix) with ESMTP for ; Tue, 4 Aug 2020 21:04:53 +0000 (UTC) Received: by mail-lf1-f68.google.com with SMTP id b30so23114407lfj.12 for ; Tue, 04 Aug 2020 14:04:53 -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=PKnGy/DpZiS1BGuPhPvnP3nG7CGqe0ye333RHTJ9F2Q=; b=ijxV/DAhKlwSitFaSXIu1XEk0os71AFmAEd/Ikq1z7GW3czVrOKl13nhEUjuGL2bo/ RQINvlbqF042Dy7qMTaI5ksu3NuFAVIEJiFrbDLdVdz8sKRfbe31J2OVWc4A2xZ1Iur6 wj7iOk5ky3qlEoV1d7msllPCwzYE09W8nBeLmX9qoHrbLokTrfxA2Yxri2vXxy9angyZ bLlT4W7UVkdOg4mL6phJkqTWIBmOxt9vne1Kn0TrwCYE5vMaSEdqDvAfSVfQoTySE6ig SiTJq9JcHIv7Xdjya6jboYFL8ssRXmGyXDD6w56d8X8iCiXb5ln2+/bw7pV1OY/FQOmx XXbA== 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=PKnGy/DpZiS1BGuPhPvnP3nG7CGqe0ye333RHTJ9F2Q=; b=tLkGCTecNFx0CcfegG4yDBCjfw0oTH4JSr7jqQe8ZkTQXu75IhfkXJ0JkeEhe5TOdK AoTHrBMBOn1b073N1tH2rmN9K+XLA9wX5Y6bLCQYsCSEyzr5Nvlpa6VptTp5K+PIQNPm 8b1MNYIRxzxG9REry/LsqwpmjzsLcpnkQyoYodyeR5Vrzx/UNBFgb6GiOs6FkdyT4lXB lE8VT8Ncb4mMYnDBvCEO4U8/1bY11Z3LkSxlwLQQKdHjjlNIemaXIqlpBuddrcpj8mwO RCPiiu7/4Q3/9p4j2tW2u0sNKZLI1MkfVsb1ybswkX8xZHhBgk+4mSxfQKlb12PjYNS9 1+gg== X-Gm-Message-State: AOAM530K0B/rI0hhPft/UG+BJt0VQ/ojjbLbc5nQzuK0dcSVgjSAb7Du d4ciNzaPP0hyFozrP32NOdA= X-Google-Smtp-Source: ABdhPJzLSXjsfjrVr7j95IjJ2hBSnQ97XDIokVkvlvAWIRJolk3lsPGM6qeTi1y9GCtT9ISNwY/Ttw== X-Received: by 2002:a19:c519:: with SMTP id w25mr46763lfe.24.1596575091566; Tue, 04 Aug 2020 14:04:51 -0700 (PDT) Received: from pc636 (h5ef52e31.seluork.dyn.perspektivbredband.net. [94.245.46.49]) by smtp.gmail.com with ESMTPSA id a9sm5510382ljb.57.2020.08.04.14.04.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Aug 2020 14:04:51 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Tue, 4 Aug 2020 23:04:48 +0200 To: Vlastimil Babka Cc: Matthew Wilcox , "Uladzislau Rezki (Sony)" , LKML , RCU , linux-mm@kvack.org, Andrew Morton , "Paul E . McKenney" , "Theodore Y . Ts'o" , Joel Fernandes , Sebastian Andrzej Siewior , Oleksiy Avramchenko Subject: Re: [RFC-PROTOTYPE 1/1] mm: Add __GFP_FAST_TRY flag Message-ID: <20200804210448.GC29837@pc636> References: <20200803163029.1997-1-urezki@gmail.com> <1d50a46a-b97f-96b2-8a5c-21075f022f01@suse.cz> <20200804171203.GH23808@casper.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Queue-Id: DE0BF28A4EA 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 Tue, Aug 04, 2020 at 07:34:18PM +0200, Vlastimil Babka wrote: > On 8/4/20 7:12 PM, Matthew Wilcox wrote: > > On Tue, Aug 04, 2020 at 07:02:14PM +0200, Vlastimil Babka wrote: > >> > 2) There was a proposal from Matthew Wilcox: https://lkml.org/lkml/2020/7/31/1015 > >> > > >> > > >> > On non-RT, we could make that lock a raw spinlock. On RT, we could > >> > decline to take the lock. We'd need to abstract the spin_lock() away > >> > behind zone_lock(zone), but that should be OK. > >> > > >> > > >> > It would be great to use any existing flag, say GFP_NOWAIT. Suppose we > >> > decline to take the lock across the page allocator for RT. But there is > >> > at least one path that does it outside of the page allocator. GFP_NOWAIT > >> > can wakeup the kswapd, whereas a "wake-up path" uses sleepable lock: > >> > > >> > wakeup_kswapd() -> wake_up_interruptible(&pgdat->kswapd_wait). > >> > > >> > Probably it can be fixed by the excluding of waking of the kswapd process > >> > defining something like below: > >> > >> Is something missing here? > >> > >> > what is equal to zero and i am not sure if __get_free_page(0) handles > >> > all that correctly, though it allocates and seems working on my test > >> > machine! Please note it is related to "if we can reuse existing flags". > >> > > >> > In the meantime, please see below for a patch that adds a __GFP_FAST_TRY, > >> > which can at least serve as a baseline against which other proposals can > >> > be compared. The patch is based on the 5.8.0-rc3. > >> > > >> > Please RFC. > >> > >> At first glance __GFP_FAST_TRY (more descriptive name? __GFP_NO_LOCKS?) seems > >> better than doing weird things with GFP_NOWAIT, but depends on the real benefits > >> (hence my first questions). > > > > I think what Vlad is trying to say is that even GFP_NOWAIT will wake > > kswapd, which involves taking a spinlock. If you specify 0 in your GFP > > flags, then we won't wake kswapd. So a simple: > > > > #define GFP_NOLOCKS 0 > > > > should do the trick (modulo various casting, blah blah blah) > > Ah, you're right, waking up kswapd is is only done with __GFP_KSWAPD_RECLAIM and > GFP_NOWAIT equals to that. So that's easy to avoid for the rcu allocation. > > But still IIUC option 2) would mean that even with "#define GFP_NOLOCKS 0" would > mean we need to abstract away the zone lock, and behave differently depending on > the kernel being RT, and inadvertedly changing other users that happen to > specify gfp where "gfp & GFP_RECLAIM_MASK == 0" (or however we would exactly > check if we can take the lock on RT kernel). That sounds too complicated to me. > I think a different behaviour, i mean RT/non-rt, is not a way forward, because the things will be over complicated. Please note, the proposed variant is common. It provides a fast access to pcp-cache, what can be done lock-less. If we could extend the "fast path" even do the lock-less prefetch(make fast path fully lock-less) from the body would be fantastic, but that is a bit out of the question. For example implement removing/inserting pages from "zone->free_area" as lock-less: llist_add()/llist_del(). But that is theory and on the high level. During investigation the things might become complicated. -- Vlad Rezki