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.5 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,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 58DDCC4727C for ; Wed, 30 Sep 2020 14:39:57 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C8A91206D4 for ; Wed, 30 Sep 2020 14:39:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C8A91206D4 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 3E8468E0003; Wed, 30 Sep 2020 10:39:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 398618E0001; Wed, 30 Sep 2020 10:39:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2AF5D8E0003; Wed, 30 Sep 2020 10:39:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 160908E0001 for ; Wed, 30 Sep 2020 10:39:56 -0400 (EDT) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id C33EB485F for ; Wed, 30 Sep 2020 14:39:55 +0000 (UTC) X-FDA: 77319987150.10.push24_460026927193 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin10.hostedemail.com (Postfix) with ESMTP id A22BB16A0D1 for ; Wed, 30 Sep 2020 14:39:55 +0000 (UTC) X-HE-Tag: push24_460026927193 X-Filterd-Recvd-Size: 4236 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf35.hostedemail.com (Postfix) with ESMTP for ; Wed, 30 Sep 2020 14:39:55 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id DC4CDABAD; Wed, 30 Sep 2020 14:39:53 +0000 (UTC) Subject: Re: [RFC-PATCH 2/4] mm: Add __rcu_alloc_page_lockless() func. To: Uladzislau Rezki Cc: LKML , RCU , linux-mm@kvack.org, Andrew Morton , "Paul E . McKenney" , Peter Zijlstra , Michal Hocko , Thomas Gleixner , "Theodore Y . Ts'o" , Joel Fernandes , Sebastian Andrzej Siewior , Oleksiy Avramchenko , Mel Gorman References: <20200918194817.48921-1-urezki@gmail.com> <20200918194817.48921-3-urezki@gmail.com> <38f42ca1-ffcd-04a6-bf11-618deffa897a@suse.cz> <20200929220742.GB8768@pc636> From: Vlastimil Babka Message-ID: <795d6aea-1846-6e08-ac1b-dbff82dd7133@suse.cz> Date: Wed, 30 Sep 2020 16:39:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <20200929220742.GB8768@pc636> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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 9/30/20 12:07 AM, Uladzislau Rezki wrote: > On Tue, Sep 29, 2020 at 12:15:34PM +0200, Vlastimil Babka wrote: >> On 9/18/20 9:48 PM, Uladzislau Rezki (Sony) wrote: >> >> After reading all the threads and mulling over this, I am going to deflect from >> Mel and Michal and not oppose the idea of lockless allocation. I would even >> prefer to do it via the gfp flag and not a completely separate path. Not using >> the exact code from v1, I think it could be done in a way that we don't actually >> look at the new flag until we find that pcplist is empty - which should not >> introduce overhead to the fast-fast path when pcpclist is not empty. It's more >> maintainable that adding new entry points, IMHO. >> > Thanks for reading all that from the beginning! It must be tough due to the > fact there were lot of messages in the threads, so at least i was lost. > > I agree that adding a new entry or separate lock-less function can be considered > as something that is hard to maintain. I have a question here. I mean about your > different look at it: > > > bool is_pcp_cache_empty(gfp_t gfp) > { > struct per_cpu_pages *pcp; > struct zoneref *ref; > unsigned long flags; > bool empty; > > ref = first_zones_zonelist(node_zonelist( > numa_node_id(), gfp), gfp_zone(gfp), NULL); > if (!ref->zone) > return true; > > local_irq_save(flags); > pcp = &this_cpu_ptr(ref->zone->pageset)->pcp; > empty = list_empty(&pcp->lists[gfp_migratetype(gfp)]); > local_irq_restore(flags); > > return empty; > } > > disable_irq(); > if (!is_pcp_cache_empty(GFP_NOWAIT)) > __get_free_page(GFP_NOWAIT); > enable_irq(); > > > Do you mean to have something like above? I mean some extra API > function that returns true or false if fast-fast allocation can > either occur or not. Above code works just fine and never touches > main zone->lock. > > i.e. Instead of introducing an extra GFP_LOCKLESS flag or any new > extra lock-less function. We could have something that checks a > pcp page cache list, thus it can guarantee that a request would > be accomplish using fast-fast path. No, I meant going back to idea of new gfp flag, but adjust the implementation in the allocator (different from what you posted in previous version) so that it only looks at the flag after it tries to allocate from pcplist and finds out it's empty. So, no inventing of new page allocator entry points or checks such as the one you wrote above, but adding the new gfp flag in a way that it doesn't affect existing fast paths.