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.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 AEA2EC64E8A for ; Thu, 3 Dec 2020 11:47:53 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 06D3C20758 for ; Thu, 3 Dec 2020 11:47:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 06D3C20758 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine 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 5A92E6B0073; Thu, 3 Dec 2020 06:47:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 55ABD6B0074; Thu, 3 Dec 2020 06:47:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 498496B0075; Thu, 3 Dec 2020 06:47:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0107.hostedemail.com [216.40.44.107]) by kanga.kvack.org (Postfix) with ESMTP id 33DB16B0073 for ; Thu, 3 Dec 2020 06:47:52 -0500 (EST) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id F1F968249980 for ; Thu, 3 Dec 2020 11:47:51 +0000 (UTC) X-FDA: 77551796742.18.need33_160e893273bb Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin18.hostedemail.com (Postfix) with ESMTP id CF37C100ED0D0 for ; Thu, 3 Dec 2020 11:47:51 +0000 (UTC) X-HE-Tag: need33_160e893273bb X-Filterd-Recvd-Size: 5479 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf13.hostedemail.com (Postfix) with ESMTP for ; Thu, 3 Dec 2020 11:47:51 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1606996070; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=WdKmdYnwmnj2SC50EKwyFiX7FW/+oQeHbUAT/XBMu74=; b=Z3WBmDj49gC8U1gp2kb3oi8QpP7B85jdgQlpkvQcvulESDp0PXpILM5nZz/hp5jw9+/afT 8hPFNYJ5G4JqUUSMaYgIeXW6dYQHvyjSu2UDffeIr/zW/ADnaQ5faqZE9Uq4gJGgqTCaSQ kils5BbwPWFohjg0fKAXoMG9UqDj1mg= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id D83D9AC75; Thu, 3 Dec 2020 11:47:49 +0000 (UTC) Date: Thu, 3 Dec 2020 12:47:48 +0100 From: Michal Hocko To: David Hildenbrand Cc: Minchan Kim , Andrew Morton , LKML , linux-mm , hyesoo.yu@samsung.com, willy@infradead.org, iamjoonsoo.kim@lge.com, vbabka@suse.cz, surenb@google.com, pullip.cho@samsung.com, joaodias@google.com, hridya@google.com, sumit.semwal@linaro.org, john.stultz@linaro.org, Brian.Starkey@arm.com, linux-media@vger.kernel.org, devicetree@vger.kernel.org, robh@kernel.org, christian.koenig@amd.com, linaro-mm-sig@lists.linaro.org Subject: Re: [PATCH v2 2/4] mm: introduce cma_alloc_bulk API Message-ID: <20201203114748.GB17338@dhcp22.suse.cz> References: <8f006a4a-c21d-9db3-5493-fb1cc651b0cf@redhat.com> <20201202154915.GU17338@dhcp22.suse.cz> <20201202164834.GV17338@dhcp22.suse.cz> <20201202185107.GW17338@dhcp22.suse.cz> <20201203082810.GX17338@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 03-12-20 10:47:02, David Hildenbrand wrote: > On 03.12.20 09:28, Michal Hocko wrote: [...] > > I think we should aim at easy and very highlevel behavior: > > - GFP_NOWAIT - unsupported currently IIRC but something that something > > that should be possible to implement. Isolation is non blocking, > > migration could be skipped > > - GFP_KERNEL - default behavior whatever that means > > - GFP_NORETRY - opportunistic allocation as lightweight as we can get. > > Failures to be expected also for transient reasons. > > - GFP_RETRY_MAYFAIL - try hard but not as hard as to trigger disruption > > (e.g. via oom killer). > > I think we currently see demand for 3 modes for alloc_contig_range() > > a) normal > > As is. Try, but don't try too hard. E.g., drain LRU, drain PCP, retry a > couple of times. Failures in some cases (short-term pinning, PCP races) > are still possible and acceptable. > > GFP_RETRY_MAYFAIL ? normal shouldn't really require anybody to think about gfp flags hard. That to most people really means GFP_KERNEL. > E.g., "Allocations with this flag may fail, but only when there is > genuinely little unused memory." - current description does not match at > all. When allocating ranges things behave completely different. > > > b) fast > > Try, but fail fast. Leave optimizations that can improve the result to > the caller. E.g., don't drain LRU, don't drain PCP, don't retry. > Frequent failures are expected and acceptable. > > __GFP_NORETRY ? > > E.g., "The VM implementation will try only very lightweight memory > direct reclaim to get some memory under memory pressure" - again, I > think current description does not really match. Agreed. As mentioned above this would be an opportunistic allocation mode. > c) hard > > Try hard, E.g., temporarily disabling the PCP. Certainly not > __GFP_NOFAIL, that would be highly dangerous. So no flags / GFP_KERNEL? NOFAIL semantic is out of question. Should we have a mode to try harder than the default? I dunno. Do we have users? I think RETRY_MAYFAIL is a middle ground between the default and NORETRY which is just too easy to fail. This is the case for the allocator as well. And from what I have seen people are already using MAYFAIL in order to prevent oom killer so this is a generally recognized pattern. > > - __GFP_THIS_NODE - stick to a node without fallback > > - we can support zone modifiers although there is no existing user. > > - __GFP_NOWARN - obvious > > > > And that is it. Or maybe I am seeing that oversimplified. > > > > Again, I think most flags make sense for the migration target allocation > path and mainly deal with OOM situations and reclaim. For the migration > path - which is specific to the alloc_contig_range() allocater - they > don't really apply and create more confusion than they actually help - IMHO. Migration is really an implementation detail of this interface. You shouldn't be even thinking that there is a migration underneath not even mention to actually trying to control it. But well, we might end up disagreeing here. What actually matters is existing users of the interface. -- Michal Hocko SUSE Labs