On 9 December 2011 21:52, Kevin Winchester <kjwinchester@xxxxxxxxx> wrote: > On 9 December 2011 03:22, Ingo Molnar <mingo@xxxxxxx> wrote: >> >> * Kevin Winchester <kjwinchester@xxxxxxxxx> wrote: >> >>> On 6 December 2011 01:50, Ingo Molnar <mingo@xxxxxxx> wrote: >>> > >>> > >>> > Ideally i think c->phys_proc_id should should be available >>> > regardless of CONFIG_SMP or CONFIG_NUMA considerations - but >>> > that would be a wider change. (feel free to have a shot at it >>> > though, in addition to the fix above) >>> > >>> >>> If Steffen does not plan to do this additional cleanup, I >>> would give it a try. You would likely prefer the changes >>> against -tip, correct? >> >> On a second thought, the !SMP block in processor.h::cpuinfo_x86 >> is pretty self-contained and making it unconditional would >> increase UP kernel size by 4x5==20 bytes. >> >> I have not checked how many further simplifications this allows >> - if it's a really nice cleanup then i guess we could do it and >> keep the all-zeroes-and-ones default value on UP. >> >> The fields *do* make sense on UP as well. >> >> So it's a "try and see how it ends up" thing. >> > > So I get the following (gmail-mangled) patch as a cleanup if the > fields are made available on UP. Is it worth it? I'll let you be the > judge. One other thing I noticed that prevented a few more #ifdef > removals was the global smp_num_siblings variable defined in > smpboot.c. This variable appears related to hyperthreading siblings > from what I can tell, but it gets used in ways related to the cpu > info. Would it be possible to move this into a new field in struct > cpuinfo_x86? It seems like a cpu-related property to me, not that I > can imagine there will ever be a processor architecture where > different cpus have different numbers of HT threads. > > In any case, if you like the simple cleanup, I can resend with sign > off and no whitespace damage. If you want me to go further, let me > know and I'll give it a shot. > > arch/x86/include/asm/processor.h | 2 -- > arch/x86/kernel/amd_nb.c | 8 ++------ > arch/x86/kernel/cpu/amd.c | 2 -- > arch/x86/kernel/cpu/common.c | 7 ------- > arch/x86/kernel/cpu/intel.c | 2 -- > arch/x86/kernel/cpu/mcheck/mce.c | 2 -- > arch/x86/kernel/cpu/mcheck/mce_amd.c | 7 +------ > arch/x86/kernel/cpu/proc.c | 4 +--- > drivers/edac/sb_edac.c | 2 -- > drivers/hwmon/coretemp.c | 6 ------ > 10 files changed, 4 insertions(+), 38 deletions(-) > A couple of other notes: - For my config, converted to !SMP, the size of the kernel text grew by 267 bytes: text data bss dec hex filename 4734483 510391 972040 6216914 5edcd2 vmlinux.o.before 4734750 510391 972040 6217181 5edddd vmlinux.o.after Maybe that makes it no longer worthwhile for removing 34 lines of code... - The booted_cores field is only set in smpboot.c, and only used there and in cpu/proc.c in a SMP-specific block of code. I wasn't sure where the best place would be to set it for the UP case, so I left it alone. That technically makes it wrong since it will be 0 when there really is one core booted, but no one will notice. If you have a suggestion for initializing it, let me know and I can include it. And in case anyone is wondering, I am aware that this is pretty basic in nature and not necessarily worth anyone's time to code/review. But it gives me a little more insight into the kernel codebase, so I'm happy to do it anyway. -- Kevin Winchester -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|