Please unsubscribe me from... wait, that's not what I meant to say. Any thoughts or questions on this one? I posted this right before the holidays so my feelings aren't hurt by the lack of response (yet!)
To summarize why I think this should go in 2.6.29: - Userspace will now be able to determine the true cache topology (the current code doesn't tell you which caches are shared between CPUs). - More complete information will be presented on systems that use [di]-cache-block-size properties instead of [di]-cache-line-size. - While overall LOC has increased, the documentation is better, and the functions are much shorter and less complex. Nathan Lynch wrote: > The current code for providing processor cache information in sysfs > has the following deficiencies: > - several complex functions that are hard to understand > - implicit recursion (cache_desc_release -> kobject_put -> cache_desc_release) > - explicit recursion (create_cache_index_info) > - use of two per-cpu arrays when one would suffice > - duplication of work on systems where CPUs share cache > > Also, when I looked at implementing support for a shared_cpu_map > attribute, it was pretty much impossible to handle hotplug without > checking every single online CPU's cache_desc list and fixing things > up... not that this is a hot path, but it would have introduced > O(n^2)-ish behavior during boot. Addressing this involved rethinking > the core data structures used, which didn't lend itself to an > incremental approach. > > This implementation maintains a "forest" (potentially more than one > tree) of cache objects which reflects the system's cache topology. > Cache objects are instantiated as needed as CPUs come online. A > per-cpu array is used mainly for sysfs-related bookkeeping; the > objects in the array just point to the appropriate points in the > forest. > > This maintains compatibility with the existing code and includes some > enhancements: > - Implement the shared_cpu_map attribute, which is essential for > enabling userspace to discover the system's overall cache topology. > - Use cache-block-size properties if cache-line-size is not available. > > I chose to place this implementation in a new file since it would have > roughly doubled the size of sysfs.c, which is already kind of messy. > > Signed-off-by: Nathan Lynch <n...@pobox.com> > --- > arch/powerpc/kernel/Makefile | 2 +- > arch/powerpc/kernel/cacheinfo.c | 837 > +++++++++++++++++++++++++++++++++++++++ > arch/powerpc/kernel/cacheinfo.h | 8 + > arch/powerpc/kernel/sysfs.c | 300 +-------------- > 4 files changed, 850 insertions(+), 297 deletions(-) > create mode 100644 arch/powerpc/kernel/cacheinfo.c > create mode 100644 arch/powerpc/kernel/cacheinfo.h > > I've tested this on various ppc64 systems, making sure that the cache > attributes' output remain unchanged, as well as running cpu hotplug > stress tests while concurrently accessing the cpu sysfs hierarchy. > _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
