mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Michael Ellerman <michael@ellerman.id.au>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1] powerpc/pseries: CMM: Drop page array
Date: Mon, 30 Sep 2019 09:52:15 +0200	[thread overview]
Message-ID: <982d2b2f-203b-89fe-6e91-5dc401af90cf@redhat.com> (raw)
In-Reply-To: <27742115-E5A4-4DF1-B223-5E6EB7A6E4F3@ellerman.id.au>

On 27.09.19 23:06, Michael Ellerman wrote:
> 
> 
> On 27 September 2019 9:19:49 pm AEST, David Hildenbrand <david@redhat.com> wrote:
>> On 25.09.19 09:37, David Hildenbrand wrote:
>>> On 10.09.19 18:39, David Hildenbrand wrote:
>>>> We can simply store the pages in a list (page->lru), no need for a
>>>> separate data structure (+ complicated handling). This is how most
>>>> other balloon drivers store allocated pages without additional
>> tracking
>>>> data.
>>>>
>>>> For the notifiers, use page_to_pfn() to check if a page is in the
>>>> applicable range. plpar_page_set_loaned()/plpar_page_set_active()
>> were
>>>> called with __pa(page_address()) for now, I assume we can simply
>> switch
>>>> to page_to_phys() here. The pfn_to_kaddr() handling is now mostly
>> gone.
>>>>
>>>> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>>>> Cc: Paul Mackerras <paulus@samba.org>
>>>> Cc: Michael Ellerman <mpe@ellerman.id.au>
>>>> Cc: Arun KS <arunks@codeaurora.org>
>>>> Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
>>>> Cc: Thomas Gleixner <tglx@linutronix.de>
>>>> Cc: Andrew Morton <akpm@linux-foundation.org>
>>>> Cc: Vlastimil Babka <vbabka@suse.cz>
>>>> Signed-off-by: David Hildenbrand <david@redhat.com>
>>>> ---
>>>>
>>>> Only compile-tested. I hope the page_to_phys() thingy is correct and
>> I
>>>> didn't mess up something else / ignoring something important why the
>> array
>>>> is needed.
>>>>
>>>> I stumbled over this while looking at how the memory isolation
>> notifier is
>>>> used - and wondered why the additional array is necessary. Also, I
>> think
>>>> by switching to the generic balloon compaction mechanism, we could
>> get
>>>> rid of the memory hotplug notifier and the memory isolation notifier
>> in
>>>> this code, as the migration capability of the inflated pages is the
>> real
>>>> requirement:
>>>> 	commit 14b8a76b9d53346f2871bf419da2aaf219940c50
>>>> 	Author: Robert Jennings <rcj@linux.vnet.ibm.com>
>>>> 	Date:   Thu Dec 17 14:44:52 2009 +0000
>>>> 	
>>>> 	    powerpc: Make the CMM memory hotplug aware
>>>> 	
>>>> 	    The Collaborative Memory Manager (CMM) module allocates
>> individual pages
>>>> 	    over time that are not migratable.  On a long running system
>> this can
>>>> 	    severely impact the ability to find enough pages to support a
>> hotplug
>>>> 	    memory remove operation.
>>>> 	[...]
>>>>
>>>> Thoughts?
>>>
>>> Ping, is still feature still used at all?
>>>
>>> If nobody can test, any advise on which HW I need and how to trigger
>> it?
>>>
>>
>> So ... if CMM is no longer alive I propose ripping it out completely.
>> Does anybody know if this feature is still getting used? Getting rid of
>> the memory isolation notifier sounds desirable - either by scrapping
>> CMM
>> or by properly wiring up balloon compaction.
> 
> It's still used AFAIK, but the people who wrote the code have left IBM, and I'm on leave.
> 
> I'll be back in a week or so and will try and track down how to test it then.
> 

Thanks - sure, take your time. I'll try to play with wiring up balloon
compaction in the meantime.

Cheers!

> cheers
> 


-- 

Thanks,

David / dhildenb

      reply	other threads:[~2019-09-30  7:52 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-10 16:39 David Hildenbrand
2019-09-25  7:37 ` David Hildenbrand
2019-09-27 11:19   ` David Hildenbrand
2019-09-27 21:06     ` Michael Ellerman
2019-09-30  7:52       ` David Hildenbrand [this message]

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=982d2b2f-203b-89fe-6e91-5dc401af90cf@redhat.com \
    --to=david@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael@ellerman.id.au \
    /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

all inboxes | Powered by JetHome®