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=-4.0 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 490A6C433DF for ; Thu, 13 Aug 2020 13:41:45 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1854D2078D for ; Thu, 13 Aug 2020 13:41:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1854D2078D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B1D6A6B0002; Thu, 13 Aug 2020 09:41:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AA7816B0003; Thu, 13 Aug 2020 09:41:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 971AB6B0010; Thu, 13 Aug 2020 09:41:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0021.hostedemail.com [216.40.44.21]) by kanga.kvack.org (Postfix) with ESMTP id 7CEC96B0002 for ; Thu, 13 Aug 2020 09:41:44 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id D708E180AD806 for ; Thu, 13 Aug 2020 13:41:43 +0000 (UTC) X-FDA: 77145658086.08.park28_420d01d26ff4 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin08.hostedemail.com (Postfix) with ESMTP id CEC5E1819E62C for ; Thu, 13 Aug 2020 13:41:41 +0000 (UTC) X-HE-Tag: park28_420d01d26ff4 X-Filterd-Recvd-Size: 2832 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf13.hostedemail.com (Postfix) with ESMTP for ; Thu, 13 Aug 2020 13:41:41 +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 506B6B153; Thu, 13 Aug 2020 13:42:02 +0000 (UTC) Date: Thu, 13 Aug 2020 15:41:39 +0200 From: Michal Hocko To: Uladzislau Rezki Cc: Thomas Gleixner , paulmck@kernel.org, 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: <20200813134039.GL9477@dhcp22.suse.cz> References: <20200811210931.GZ4295@paulmck-ThinkPad-P72> <874kp87mca.fsf@nanos.tec.linutronix.de> <20200813075027.GD9477@dhcp22.suse.cz> <20200813095840.GA25268@pc636> <20200813132931.GA26290@pc636> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200813132931.GA26290@pc636> X-Rspamd-Queue-Id: CEC5E1819E62C X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 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 Thu 13-08-20 15:29:31, Uladzislau Rezki wrote: [...] > I was a bit out of focus and did not mention about one thing. Identifying the context > type using preemtable() primitives looks a bit not suitable, IMHO. GFP_* flags are > not supposed to identify a context type, because it is not possible for all cases. Yes, GFP flags do not identify context and that is why my draft didn't really consider gfp flags for anything but the retry logic which is already gfp based already. The buddy allocator path simply always bails out for those rt atomic paths whenever it gets close to zone->lock > But that i You meant to say more I guess > Also, to bail out based on a context's type will not allow to get a page from atomic > contexts, what we try to achieve :) Yes lockdep will need some special treatment but I suspect we want to address the underlying problem first and only then take care of the lockdep. > Whereas, i mean, we do have possibility to do lock-less per-cpu-list allocation without > touching any zone lock. > > if (gfp_mask == 0) { > check_pcp_lists(); > if (page) > return page; > > bail out here without doing farther logic, like pre-fetching. > return NULL; > } The existing code does that already. __rmqueue_pcplist will go rmqueue_bulk only when pcp lists are empty. Or did I miss your point? -- Michal Hocko SUSE Labs