linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Hari Bathini <hbathini@linux.ibm.com>
To: David Hildenbrand <david@redhat.com>,
	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
Subject: Re: [PATCH 1/2] mm/cma: provide option to opt out from exposing pages on activation failure
Date: Thu, 6 Jan 2022 17:31:57 +0530	[thread overview]
Message-ID: <bc8c2655-d540-5d87-9811-054e87e84487@linux.ibm.com> (raw)
In-Reply-To: <e4748b18-3de3-b3f9-464a-e5cfcf9f05d4@redhat.com>



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...


[1] 
https://github.com/torvalds/linux/blob/master/Documentation/powerpc/firmware-assisted-dump.rst
[2] https://github.com/torvalds/linux/commit/a4e92ce8e4c8
[3] https://github.com/torvalds/linux/commit/072355c1cf2d

Thanks
Hari


  parent reply	other threads:[~2022-01-06 12:02 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-20 19:34 [PATCH 0/2] powerpc/fadump: handle CMA activation failure appropriately Hari Bathini
2021-12-20 19:34 ` [PATCH 1/2] mm/cma: provide option to opt out from exposing pages on activation failure Hari Bathini
     [not found]   ` <e4748b18-3de3-b3f9-464a-e5cfcf9f05d4@redhat.com>
2022-01-06 12:01     ` Hari Bathini [this message]
2022-01-11 14:36       ` David Hildenbrand
2022-01-12  9:50         ` Hari Bathini
2021-12-20 19:34 ` [PATCH 2/2] powerpc/fadump: opt out from freeing pages on cma " Hari Bathini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bc8c2655-d540-5d87-9811-054e87e84487@linux.ibm.com \
    --to=hbathini@linux.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mahesh@linux.ibm.com \
    --cc=mike.kravetz@oracle.com \
    --cc=mpe@ellerman.id.au \
    --cc=osalvador@suse.de \
    --cc=sourabhjain@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox