|| ||Nathan Fontenot <firstname.lastname@example.org> |
|| ||email@example.com, firstname.lastname@example.org,
|| ||[PATCH 0/9] v4 De-couple sysfs memory directories from memory sections |
|| ||Tue, 03 Aug 2010 08:32:29 -0500|
|| ||Greg KH <email@example.com>,
KAMEZAWA Hiroyuki <firstname.lastname@example.org>,
Dave Hansen <email@example.com>|
|| ||Article, Thread
This set of patches de-couples the idea that there is a single
directory in sysfs for each memory section. The intent of the
patches is to reduce the number of sysfs directories created to
resolve a boot-time performance issue. On very large systems
boot time are getting very long (as seen on powerpc hardware)
due to the enormous number of sysfs directories being created.
On a system with 1 TB of memory we create ~63,000 directories.
For even larger systems boot times are being measured in hours.
This set of patches allows for each directory created in sysfs
to cover more than one memory section. The default behavior for
sysfs directory creation is the same, in that each directory
represents a single memory section. A new file 'end_phys_index'
in each directory contains the physical_id of the last memory
section covered by the directory so that users can easily
determine the memory section range of a directory.
Updates for version 4 of the patchset includes an additional
patch [4/9] that introduces a new mutex to be taken for any
add or remove (not hotplug) of memory. The following updates
are also included.
Patch 2/9 Add new phys_index properties
- The start_phys_index property was reverted to the original
Patch 3/9 Add section count to memory_block
- Use atomic_dec_and_test()
Patch 7/9 Update the node sysfs code
- Update the inline definition of unregister_mem_sects_under_nodes
for !CONFIG_NUMA builds.
Patch 8/9 Define memory_block_size_bytes() for ppc/pseries
- Use an unsigned long for getting property value.
Patch 9/9 Update memory-hotplug documentation
- Minor updates for reversion of phys_index property name.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/