From: Robin Holt <holt@sgi.com>
To: Nathan Fontenot <nfont@austin.ibm.com>
Cc: linuxppc-dev@ozlabs.org, Greg KH <greg@kroah.com>,
linux-kernel@vger.kernel.org,
Dave Hansen <dave@linux.vnet.ibm.com>,
linux-mm@kvack.org,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Subject: Re: [PATCH 6/8] v2 Update node sysfs code
Date: Tue, 28 Sep 2010 04:29:19 -0500 [thread overview]
Message-ID: <20100928092919.GF14068@sgi.com> (raw)
In-Reply-To: <4CA0F00D.9000702@austin.ibm.com>
This patch may work, but it appears it is lacking in, at least the
link_mem_sections() function. Assuming you have a memory block covering
2GB and a section size of 128MB (some values we are toying with for
large SGI machines), you end up calling register_mem_sect_under_node()
16 times which then takes the same steps.
I think you also need:
Index: linux-2.6.32/drivers/base/node.c
===================================================================
--- linux-2.6.32.orig/drivers/base/node.c 2010-09-28 04:18:53.848448349 -0500
+++ linux-2.6.32/drivers/base/node.c 2010-09-28 04:21:35.169446261 -0500
@@ -342,6 +342,7 @@
if (!err)
err = ret;
+ pfn = section_nr_to_pfn(mem_blk->end_phys_index);
/* discard ref obtained in find_memory_block() */
kobject_put(&mem_blk->sysdev.kobj);
}
Also, I don't think I much care for the weirdness that occurs if a
memory block spans two nodes. I have not thought through how possible
(or likely) this is, but the code certainly permits it. If that were
the case, how would we know which sections need to be taken offline, etc?
I wonder how much this will muddy up the information available in sysfs.
Thanks,
Robin
On Mon, Sep 27, 2010 at 02:27:09PM -0500, Nathan Fontenot wrote:
> Update the node sysfs code to be aware of the new capability for a memory
> block to contain multiple memory sections. This requires an additional
> parameter to unregister_mem_sect_under_nodes so that we know which memory
> section of the memory block to unregister.
>
> Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
>
> ---
> drivers/base/memory.c | 2 +-
> drivers/base/node.c | 12 ++++++++----
> include/linux/node.h | 6 ++++--
> 3 files changed, 13 insertions(+), 7 deletions(-)
>
> Index: linux-next/drivers/base/node.c
> ===================================================================
> --- linux-next.orig/drivers/base/node.c 2010-09-27 13:49:36.000000000 -0500
> +++ linux-next/drivers/base/node.c 2010-09-27 13:50:43.000000000 -0500
> @@ -346,8 +346,10 @@
> return -EFAULT;
> if (!node_online(nid))
> return 0;
> - sect_start_pfn = section_nr_to_pfn(mem_blk->phys_index);
> - sect_end_pfn = sect_start_pfn + PAGES_PER_SECTION - 1;
> +
> + sect_start_pfn = section_nr_to_pfn(mem_blk->start_phys_index);
> + sect_end_pfn = section_nr_to_pfn(mem_blk->end_phys_index);
> + sect_end_pfn += PAGES_PER_SECTION - 1;
> for (pfn = sect_start_pfn; pfn <= sect_end_pfn; pfn++) {
> int page_nid;
>
> @@ -371,7 +373,8 @@
> }
>
> /* unregister memory section under all nodes that it spans */
> -int unregister_mem_sect_under_nodes(struct memory_block *mem_blk)
> +int unregister_mem_sect_under_nodes(struct memory_block *mem_blk,
> + unsigned long phys_index)
> {
> NODEMASK_ALLOC(nodemask_t, unlinked_nodes, GFP_KERNEL);
> unsigned long pfn, sect_start_pfn, sect_end_pfn;
> @@ -383,7 +386,8 @@
> if (!unlinked_nodes)
> return -ENOMEM;
> nodes_clear(*unlinked_nodes);
> - sect_start_pfn = section_nr_to_pfn(mem_blk->phys_index);
> +
> + sect_start_pfn = section_nr_to_pfn(phys_index);
> sect_end_pfn = sect_start_pfn + PAGES_PER_SECTION - 1;
> for (pfn = sect_start_pfn; pfn <= sect_end_pfn; pfn++) {
> int nid;
> Index: linux-next/drivers/base/memory.c
> ===================================================================
> --- linux-next.orig/drivers/base/memory.c 2010-09-27 13:50:38.000000000 -0500
> +++ linux-next/drivers/base/memory.c 2010-09-27 13:50:43.000000000 -0500
> @@ -587,9 +587,9 @@
>
> mutex_lock(&mem_sysfs_mutex);
> mem = find_memory_block(section);
> + unregister_mem_sect_under_nodes(mem, __section_nr(section));
>
> if (atomic_dec_and_test(&mem->section_count)) {
> - unregister_mem_sect_under_nodes(mem);
> mem_remove_simple_file(mem, phys_index);
> mem_remove_simple_file(mem, end_phys_index);
> mem_remove_simple_file(mem, state);
> Index: linux-next/include/linux/node.h
> ===================================================================
> --- linux-next.orig/include/linux/node.h 2010-09-27 13:49:36.000000000 -0500
> +++ linux-next/include/linux/node.h 2010-09-27 13:50:43.000000000 -0500
> @@ -44,7 +44,8 @@
> extern int unregister_cpu_under_node(unsigned int cpu, unsigned int nid);
> extern int register_mem_sect_under_node(struct memory_block *mem_blk,
> int nid);
> -extern int unregister_mem_sect_under_nodes(struct memory_block *mem_blk);
> +extern int unregister_mem_sect_under_nodes(struct memory_block *mem_blk,
> + unsigned long phys_index);
>
> #ifdef CONFIG_HUGETLBFS
> extern void register_hugetlbfs_with_node(node_registration_func_t doregister,
> @@ -72,7 +73,8 @@
> {
> return 0;
> }
> -static inline int unregister_mem_sect_under_nodes(struct memory_block *mem_blk)
> +static inline int unregister_mem_sect_under_nodes(struct memory_block *mem_blk,
> + unsigned long phys_index)
> {
> return 0;
> }
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2010-09-28 9:36 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-27 19:09 [PATCH 0/8] v2 De-Couple sysfs memory directories from memory sections Nathan Fontenot
2010-09-27 19:21 ` [PATCH 1/8] v2 Move find_memory_block() routine Nathan Fontenot
2010-09-27 19:22 ` [PATCH 2/8] v2 Add section count to memory_block struct Nathan Fontenot
2010-09-28 9:31 ` Robin Holt
2010-09-28 18:14 ` Nathan Fontenot
2010-09-27 19:23 ` [PATCH 3/8] v2 Add mutex for adding/removing memory blocks Nathan Fontenot
2010-09-27 19:25 ` [PATCH 4/8] v2 Allow memory block to span multiple memory sections Nathan Fontenot
2010-09-27 23:55 ` Dave Hansen
2010-09-28 18:06 ` Nathan Fontenot
2010-09-28 12:48 ` Robin Holt
2010-09-28 18:20 ` Nathan Fontenot
2010-09-27 19:26 ` [PATCH 5/8] v2 Add end_phys_index file Nathan Fontenot
2010-09-27 19:27 ` [PATCH 6/8] v2 Update node sysfs code Nathan Fontenot
2010-09-28 9:29 ` Robin Holt [this message]
2010-09-28 15:21 ` Dave Hansen
2010-09-27 19:28 ` [PATCH 7/8] v2 Define memory_block_size_bytes() for powerpc/pseries Nathan Fontenot
2010-09-27 19:28 ` [PATCH 8/8] v2 Update memory hotplug documentation Nathan Fontenot
2010-09-28 12:45 ` Avi Kivity
2010-09-28 18:18 ` Nathan Fontenot
2010-09-28 12:38 ` [PATCH 0/8] v2 De-Couple sysfs memory directories from memory sections Robin Holt
2010-09-28 18:17 ` Nathan Fontenot
2010-09-29 19:28 ` Robin Holt
2010-09-30 15:17 ` Nathan Fontenot
2010-09-30 16:39 ` Robin Holt
2010-09-28 12:44 ` Avi Kivity
2010-09-28 15:12 ` Robin Holt
2010-09-28 16:34 ` Avi Kivity
2010-09-29 2:50 ` Greg KH
2010-09-29 8:32 ` Avi Kivity
2010-09-29 12:37 ` Greg KH
2010-09-29 13:39 ` Kay Sievers
2010-10-03 7:52 ` Avi Kivity
2010-09-28 15:17 ` Dave Hansen
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=20100928092919.GF14068@sgi.com \
--to=holt@sgi.com \
--cc=dave@linux.vnet.ibm.com \
--cc=greg@kroah.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=nfont@austin.ibm.com \
/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;
as well as URLs for NNTP newsgroup(s).