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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A1193C433EF for ; Tue, 11 Jan 2022 14:36:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C21AE6B0072; Tue, 11 Jan 2022 09:36:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BAA166B0073; Tue, 11 Jan 2022 09:36:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A243C6B0074; Tue, 11 Jan 2022 09:36:56 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0178.hostedemail.com [216.40.44.178]) by kanga.kvack.org (Postfix) with ESMTP id 8C1346B0072 for ; Tue, 11 Jan 2022 09:36:56 -0500 (EST) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 499BB8248D52 for ; Tue, 11 Jan 2022 14:36:55 +0000 (UTC) X-FDA: 79018257990.02.DF31419 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf30.hostedemail.com (Postfix) with ESMTP id 720918000D for ; Tue, 11 Jan 2022 14:36:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1641911813; 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=VWH4n5tZJqT8cw2gkTDGj1xvEUu3fTS/zJOrhm0MBxk=; b=GQrs9x9+twPUwGj8QWFDuA/XwKIzwPfFWkrKRrAtVaOnqtXP6hQ0wo80Z6Hu1M06UV9P8D W7j5BnHxgXuQeRuzDOVMLVf/Hn9AkrFZmwRP0SF4JN5RujaBMdzBRo5Syh64IaNxwlOmu4 kh3I6GZ58ca2SdCI2sf5R0YS9rlCx18= Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-492-ilZb3PyWPkmtH3ifRqkpWg-1; Tue, 11 Jan 2022 09:36:52 -0500 X-MC-Unique: ilZb3PyWPkmtH3ifRqkpWg-1 Received: by mail-ed1-f71.google.com with SMTP id z10-20020a05640235ca00b003f8efab3342so13487991edc.2 for ; Tue, 11 Jan 2022 06:36:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:cc:references:from:organization:subject :in-reply-to:content-transfer-encoding; bh=VWH4n5tZJqT8cw2gkTDGj1xvEUu3fTS/zJOrhm0MBxk=; b=APz4o2DVAF4vxJp0wLFACl0XURmrOKlgbopYhCYmIymWDSULgeJk/mrnJhT+rA42BE +ebEZuTFF7X063Scrsmw+w+dhi0f9+irCdMMZY1PACoS2Mdc/yL3qEMkfeNxLHrfwEfS ejai4L5w4Jw337rfMyIymGJk3U2WvXmWbQtVrjVpzgnOBUe6FtzuFyPHCdnh55BFShbr QaKwxt4WOmfumewMUN10I6xKw/2I/9G+89wMRduYmTehKSByXp4v3BHr0vP/rEyNhoDF opxVYG0SiOcI8GjvoYRxdhF8rljdajzT/jCKFBa2v1X1zaT0AKWSHffedUFeOiFn18Oh 8ILQ== X-Gm-Message-State: AOAM5310+pOaCxlI0bYwgMT4j4Mn7IiEAGK544FPZ/jz/1CVFDNOEsAP CxjTrscpXp3RLgaSTl14ggBSld8x2KPRNg6rpsmgXS3i+HbNHPib0tsM7AsPOK+usahM/xrP7sA xW2mhk/aC0ao= X-Received: by 2002:a17:906:bcd6:: with SMTP id lw22mr3760622ejb.114.1641911811232; Tue, 11 Jan 2022 06:36:51 -0800 (PST) X-Google-Smtp-Source: ABdhPJx2qYKUaa7jdLHRpdkbMwKfB/8KP3UpvHw3b/n+6Yn4uJh0st9iWVQWQ6qy6lDX1YtAZ+HRZQ== X-Received: by 2002:a17:906:bcd6:: with SMTP id lw22mr3760601ejb.114.1641911810975; Tue, 11 Jan 2022 06:36:50 -0800 (PST) Received: from ?IPV6:2003:cb:c702:6800:150a:bea9:f03e:c4da? (p200300cbc7026800150abea9f03ec4da.dip0.t-ipconnect.de. [2003:cb:c702:6800:150a:bea9:f03e:c4da]) by smtp.gmail.com with ESMTPSA id qb2sm3633062ejc.219.2022.01.11.06.36.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 11 Jan 2022 06:36:50 -0800 (PST) Message-ID: <21364354-83d1-5a56-378e-8ca07ccf9957@redhat.com> Date: Tue, 11 Jan 2022 15:36:44 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 To: Hari Bathini , akpm@linux-foundation.org, linux-mm@kvack.org, mpe@ellerman.id.au, linuxppc-dev@lists.ozlabs.org Cc: mike.kravetz@oracle.com, mahesh@linux.ibm.com, sourabhjain@linux.ibm.com, osalvador@suse.de References: <20211220193419.104242-1-hbathini@linux.ibm.com> <20211220193419.104242-2-hbathini@linux.ibm.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH 1/2] mm/cma: provide option to opt out from exposing pages on activation failure In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 720918000D X-Stat-Signature: j4ozbe6hurb5oc7h39bzcwdqtd1z1ux8 Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=GQrs9x9+; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf30.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=david@redhat.com X-Rspamd-Server: rspam03 X-HE-Tag: 1641911814-805891 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 06.01.22 13:01, Hari Bathini wrote: > > > On 22/12/21 12:18 am, David Hildenbrand wrote: >> On 20.12.21 20:34, Hari Bathini wrote: >>> Commit 072355c1cf2d ("mm/cma: expose all pages to the buddy if >>> activation of an area fails") started exposing all pages to buddy >>> allocator on CMA activation failure. But there can be CMA users that >>> want to handle the reserved memory differently on CMA allocation >>> failure. Provide an option to opt out from exposing pages to buddy >>> for such cases. > > Hi David, > > Sorry, I could not get back on this sooner. I went out on vacation > and missed this. > . > >> >> Can you elaborate why that is important and what the target user can >> actually do with it? > Previously, firmware-assisted dump [1] used to reserve memory that it > needs for booting a capture kernel & offloading /proc/vmcore. > This memory is reserved, basically blocked from being used by > production kernel, to ensure kernel crash context is not lost on > booting into a capture kernel from this memory chunk. > > But [2] started using CMA instead to let the memory be used at least > in some cases as long as this memory is not going to have kernel pages. > So, the intention in using CMA was to keep the memory unused if CMA > activation fails and only let it be used for some purpose, if at all, > if CMA activation succeeds. But [3] breaks that assumption reporting > weird errors on vmcore captured with fadump, when CMA activation fails. > > To answer the question, fadump does not want the memory to be used for > kernel pages, if CMA activation fails... Okay, so what you want is a reserved region, and if possible, let CMA use that memory for other (movable allocation) purposes until you actually need that area and free it up by using CMA. If CMA cannot use the region because of zone issues, you just want that region to stay reserved. I guess the biggest different to other CMA users is that it can make use of the memory even if not allocated via CMA -- because it's going to make use of the the physical memory range indirectly via a HW facility, not via any "struct page" access. I wonder if we can make the terminology a bit clearer, the freeing part is a bit confusing, because init_cma_reserved_pageblock() essentially also frees pages, just to the MIGRATE_CMA lists ... what you want is to treat it like a simple memblock allocation/reservation on error. What about: * cma->reserve_pages_on_error that defaults to false * void __init cma_reserve_pages_on_error(struct cma *cma) -- Thanks, David / dhildenb