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=-8.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham 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 D2839C63777 for ; Thu, 3 Dec 2020 11:57:55 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 429962086A for ; Thu, 3 Dec 2020 11:57:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 429962086A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id AF0966B005C; Thu, 3 Dec 2020 06:57:54 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A7A7A6B005D; Thu, 3 Dec 2020 06:57:54 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 941D16B0068; Thu, 3 Dec 2020 06:57:54 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0069.hostedemail.com [216.40.44.69]) by kanga.kvack.org (Postfix) with ESMTP id 788856B005D for ; Thu, 3 Dec 2020 06:57:54 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 3A4388249980 for ; Thu, 3 Dec 2020 11:57:54 +0000 (UTC) X-FDA: 77551822068.28.hour98_1a07b4c273bb Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin28.hostedemail.com (Postfix) with ESMTP id 1145A6D64 for ; Thu, 3 Dec 2020 11:57:54 +0000 (UTC) X-HE-Tag: hour98_1a07b4c273bb X-Filterd-Recvd-Size: 6582 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by imf18.hostedemail.com (Postfix) with ESMTP for ; Thu, 3 Dec 2020 11:57:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1606996672; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=M5evlQsm8Ay94bBHskraRsgd1pOfpO8SAw1wYTzWP7Q=; b=atVd7e88dDaJBvKOfz2W1JXMLg17ddbSXGUv6DP1SomR+seZQB6v1cTmzZjPjAi/vh4LoY vOm6wTiB99f0YwUAIAOXjzYN02R6k/NO6w2O+rm4cXmsqu5O6+Sfv1NzQXqccxnPsqF9y0 lVgb+DuLbvDGAW5EFHf9N1//GyQg9c0= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-82-HS7KDxt4PYeY9vmr6b1FAg-1; Thu, 03 Dec 2020 06:57:49 -0500 X-MC-Unique: HS7KDxt4PYeY9vmr6b1FAg-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id F02E884A5E0; Thu, 3 Dec 2020 11:57:45 +0000 (UTC) Received: from [10.36.113.250] (ovpn-113-250.ams2.redhat.com [10.36.113.250]) by smtp.corp.redhat.com (Postfix) with ESMTP id 00F485D9CA; Thu, 3 Dec 2020 11:57:40 +0000 (UTC) Subject: Re: [PATCH v2 2/4] mm: introduce cma_alloc_bulk API To: Michal Hocko 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 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> <20201203114748.GB17338@dhcp22.suse.cz> From: David Hildenbrand Organization: Red Hat GmbH Message-ID: <3a512f9c-a8e5-88ed-676a-7b9d4fb94a6c@redhat.com> Date: Thu, 3 Dec 2020 12:57:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: <20201203114748.GB17338@dhcp22.suse.cz> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 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 03.12.20 12:47, Michal Hocko wrote: > 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. virtio-mem might be one user. It might first try in normal mode to get as much memory out as possible, but switch to hard mode when it might make sense. > >>> - __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. CMA? I tend to agree. alloc_contig_range? I disagree. -- Thanks, David / dhildenb