Prev: [2.6.36, patch] unprotected access to task credentials in waitid()
Next: [PATCH 6/9] v4 Update the find_memory_block declaration
From: Nathan Fontenot on 3 Aug 2010 09:40 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 phys_index name. 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. Thanks, Nathan Fontenot -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |