LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Yasunori Goto <y-goto@jp.fujitsu.com>
To: Dave Hansen <haveblue@us.ibm.com>, Badari Pulavarty <pbadari@us.ibm.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Andrew Morton <akpm@linux-foundation.org>,
lkml <linux-kernel@vger.kernel.org>,
greg@kroah.com, linux-mm <linux-mm@kvack.org>
Subject: Re: [-mm PATCH] register_memory/unregister_memory clean ups
Date: Wed, 13 Feb 2008 14:09:55 +0900 [thread overview]
Message-ID: <20080213120746.FB76.Y-GOTO@jp.fujitsu.com> (raw)
In-Reply-To: <1202853976.11188.86.camel@nimitz.home.sr71.net>
Thanks Badari-san.
I understand what was occured. :-)
> On Tue, 2008-02-12 at 13:56 -0800, Badari Pulavarty wrote:
> > > > + /*
> > > > + * Its ugly, but this is the best I can do - HELP !!
> > > > + * We don't know where the allocations for section memmap and usemap
> > > > + * came from. If they are allocated at the boot time, they would come
> > > > + * from bootmem. If they are added through hot-memory-add they could be
> > > > + * from sla or vmalloc. If they are allocated as part of hot-mem-add
> > > > + * free them up properly. If they are allocated at boot, no easy way
> > > > + * to correctly free them :(
> > > > + */
> > > > + if (usemap) {
> > > > + if (PageSlab(virt_to_page(usemap))) {
> > > > + kfree(usemap);
> > > > + if (memmap)
> > > > + __kfree_section_memmap(memmap, nr_pages);
> > > > + }
> > > > + }
> > > > +}
> > >
> > > Do what we did with the memmap and store some of its origination
> > > information in the low bits.
> >
> > Hmm. my understand of memmap is limited. Can you help me out here ?
>
> Never mind. That was a bad suggestion. I do think it would be a good
> idea to mark the 'struct page' of ever page we use as bootmem in some
> way. Perhaps page->private?
I agree. page->private is not used by bootmem allocator.
I would like to mark not only memmap but also pgdat (and so on)
for next step. It will be necessary for removing whole node. :-)
> Otherwise, you can simply try all of the
> possibilities and consider the remainder bootmem. Did you ever find out
> if we properly initialize the bootmem 'struct page's?
>
> Please have mercy and put this in a helper, first of all.
>
> static void free_usemap(unsigned long *usemap)
> {
> if (!usemap_
> return;
>
> if (PageSlab(virt_to_page(usemap))) {
> kfree(usemap)
> } else if (is_vmalloc_addr(usemap)) {
> vfree(usemap);
> } else {
> int nid = page_to_nid(virt_to_page(usemap));
> bootmem_fun_here(NODE_DATA(nid), usemap);
> }
> }
>
> right?
It may work. But, to be honest, I feel there are TOO MANY allocation/free
way for memmap (usemap and so on). If possible, I would like to
unify some of them. I would like to try it.
Bye.
--
Yasunori Goto
next prev parent reply other threads:[~2008-02-13 5:14 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-11 17:23 Badari Pulavarty
2008-02-11 17:54 ` Greg KH
2008-02-11 18:05 ` Badari Pulavarty
2008-02-11 19:48 ` Andrew Morton
2008-02-11 20:35 ` Greg KH
2008-02-11 21:32 ` Badari Pulavarty
2008-02-12 8:06 ` Yasunori Goto
2008-02-12 17:22 ` Badari Pulavarty
2008-02-12 20:59 ` Dave Hansen
2008-02-12 21:56 ` Badari Pulavarty
2008-02-12 21:57 ` Dave Hansen
2008-02-12 22:07 ` Badari Pulavarty
2008-02-12 22:15 ` Dave Hansen
2008-02-12 22:51 ` Badari Pulavarty
2008-02-12 23:03 ` Badari Pulavarty
2008-02-12 23:20 ` Dave Hansen
2008-02-12 22:06 ` Dave Hansen
2008-02-13 5:09 ` Yasunori Goto [this message]
2008-02-13 17:31 ` Badari Pulavarty
2008-02-19 19:43 ` patch driver-core-register_memory-unregister_memory-clean-ups-and-bugfix.patch added to gregkh-2.6 tree gregkh
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=20080213120746.FB76.Y-GOTO@jp.fujitsu.com \
--to=y-goto@jp.fujitsu.com \
--cc=akpm@linux-foundation.org \
--cc=greg@kroah.com \
--cc=haveblue@us.ibm.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pbadari@us.ibm.com \
--subject='Re: [-mm PATCH] register_memory/unregister_memory clean ups' \
/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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).