From: Greg KH <greg@kroah.com>
To: Andrew Morton <akpm@osdl.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
linux-kernel@vger.kernel.org, lhms-devel@lists.sourceforge.net
Subject: Re: [PATCH] catch valid mem range at onlining memory
Date: Fri, 28 Apr 2006 16:44:10 -0700 [thread overview]
Message-ID: <20060428234410.GA7598@kroah.com> (raw)
In-Reply-To: <20060428163409.389e895e.akpm@osdl.org>
On Fri, Apr 28, 2006 at 04:34:09PM -0700, Andrew Morton wrote:
> KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> >
> > This patch allows hot-add memory which is not aligned to section.
> > Based on linux-2.6.17-rc2-mm1 + memory hotadd ioresource register patch.
> >
> > iomem resource patch is here.
> > http://www.uwsg.indiana.edu/hypermail/linux/kernel/0604.3/1188.html
> >
> > Now, hot-added memory has to be aligned to section size.
> > Considering big section sized archs, this is not useful.
> >
> > When hot-added memory is registerd as iomem resoruce by iomem resource patch,
> > we can make use of that information to detect valid memory range.
> >
> > Note: With this, not-aligned memory can be registerd. To allow hot-add
> > memory with holes, we have to do more work around add_memory().
> > (It doesn't allows add memory to already existing mem section.)
> >
> >
>
> Looks sane, thanks.
>
> > +#ifdef CONFIG_MEMORY_HOTPLUG
> > +/*
> > + * Finds the lowest memory reosurce exists within [res->start.res->end)
> > + * the caller must specify res->start, res->end, res->flags.
> > + * If found, returns 0, res is overwritten, if not found, returns -1.
> > + */
> > +int find_next_system_ram(struct resource *res)
> > +{
> > + u64 start, end;
> > + struct resource *p;
> > +
> > + BUG_ON(!res);
> > +
> > + start = res->start;
> > + end = res->end;
> > +
> > + read_lock(&resource_lock);
> > + for( p = iomem_resource.child; p ; p = p->sibling) {
> > + /* system ram is just marked as IORESOURCE_MEM */
> > + if (p->flags != res->flags)
> > + continue;
> > + if (p->start > end) {
> > + p = NULL;
> > + break;
> > + }
> > + if (p->start >= start)
> > + break;
> > + }
> > + read_unlock(&resource_lock);
> > + if (!p)
> > + return -1;
> > + /* copy data */
> > + res->start = p->start;
> > + res->end = p->end;
> > + return 0;
> > +}
> > +
> > +#endif
>
> This all looks fairly (but trivially) dependent upon the 64-bit-resource
> patches in Greg's tree. Greg, were you planning on merging them in the
> post-2.6.17 flood?
Yes, I was, unless there are any objections to me doing this?
thanks,
greg k-h
next prev parent reply other threads:[~2006-04-28 23:45 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-28 2:47 [PATCH] catch valid mem range at onlining memory KAMEZAWA Hiroyuki
2006-04-28 23:34 ` Andrew Morton
2006-04-28 23:44 ` Greg KH [this message]
2006-04-29 0:05 ` Andrew Morton
2006-04-29 7:18 ` Greg KH
2006-04-29 23:26 ` Vivek Goyal
2006-04-29 23:40 ` Andrew Morton
2006-05-02 20:42 ` Vivek Goyal
2006-05-03 13:25 ` Andrew Morton
2006-04-29 0:21 ` KAMEZAWA Hiroyuki
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=20060428234410.GA7598@kroah.com \
--to=greg@kroah.com \
--cc=akpm@osdl.org \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=lhms-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
/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