LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Dave Hansen <haveblue@us.ibm.com>
To: Badari Pulavarty <pbadari@us.ibm.com>
Cc: Yasunori Goto <y-goto@jp.fujitsu.com>,
	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: Tue, 12 Feb 2008 14:06:16 -0800	[thread overview]
Message-ID: <1202853976.11188.86.camel@nimitz.home.sr71.net> (raw)
In-Reply-To: <1202853415.25604.59.camel@dyn9047017100.beaverton.ibm.com>

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

> I was trying to use free_bootmem_node() to free up the allocations,
> but I need nodeid from which allocation came from :(

How is this any different from pfn_to_nid() on the thing?  Or, can you
not use that because we never init'd the bootmem 'struct page's?

If so, I think the *CORRECT* fix is to give the bootmem areas real
struct pages, probably at boot-time.

-- Dave


  parent reply	other threads:[~2008-02-12 22:06 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 [this message]
2008-02-13  5:09               ` Yasunori Goto
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=1202853976.11188.86.camel@nimitz.home.sr71.net \
    --to=haveblue@us.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=greg@kroah.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=pbadari@us.ibm.com \
    --cc=y-goto@jp.fujitsu.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).