From: Andrew Morton <akpm@osdl.org>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: linux-kernel@vger.kernel.org, lhms-devel@lists.sourceforge.net,
Greg KH <greg@kroah.com>
Subject: Re: [PATCH] catch valid mem range at onlining memory
Date: Fri, 28 Apr 2006 16:34:09 -0700 [thread overview]
Message-ID: <20060428163409.389e895e.akpm@osdl.org> (raw)
In-Reply-To: <20060428114732.e889ad2d.kamezawa.hiroyu@jp.fujitsu.com>
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?
> ===================================================================
> --- linux-2.6.17-rc2-mm1.orig/include/linux/ioport.h 2006-04-27 18:00:16.000000000 +0900
> +++ linux-2.6.17-rc2-mm1/include/linux/ioport.h 2006-04-27 21:47:25.000000000 +0900
> @@ -105,6 +105,10 @@
> void *alignf_data);
> int adjust_resource(struct resource *res, u64 start,
> u64 size);
> +#ifdef CONFIG_MEMORY_HOTPLUG
> +/* get registered SYSTEM_RAM resources in specified area */
> +extern int find_next_system_ram(struct resource *res);
> +#endif
I'll remove the ifdefs - the only thing they give us if someone makes a
mistake is an additional compile-time warning, and I don't think that's
beneficial enough to warrant the addition of an ifdef.
next prev parent reply other threads:[~2006-04-28 23:31 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 [this message]
2006-04-28 23:44 ` Greg KH
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=20060428163409.389e895e.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=greg@kroah.com \
--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