change last level cache alignment on x86?

PATCH Alex,Shi 2 participants 6 messages Mar 1, 2012 – Mar 3, 2012 x86

Share & tools

Alex,Shi

author

2012-03-01 08:34 UTC #0 lore raw

Currently last level defined in kernel is still 128 bytes, but actually I checked intel's core2, NHM, SNB, atom, serial platforms, all of them are using 64 bytes.
I did not get detailed info on AMD platforms. Guess someone like to give the info here. So, Is if it possible to do the similar following changes to use 64 byte cache alignment in kernel?

===

arch/x86/Kconfig.cpu +1 -1

index 3c57033..f342a5a 100644
@@ -303,7 +303,7 @@ config X86_GENERIC
 config X86_INTERNODE_CACHE_SHIFT
 	int
 	default "12" if X86_VSMP
-	default "7" if NUMA
+	default "7" if NUMA && (MPENTIUM4)
 	default X86_L1_CACHE_SHIFT
 
 config X86_CMPXCHG

Alex Shi

author

2012-03-02 07:30 UTC #1 lore raw

Quoted 13 lines · Alex,Shi

Currently last level defined in kernel is still 128 bytes, but actually I checked intel's core2, NHM, SNB, atom, serial platforms, all of them are using 64 bytes.
I did not get detailed info on AMD platforms. Guess someone like to give the info here. So, Is if it possible to do the similar following changes to use 64 byte cache alignment in kernel?
===
arch/x86/Kconfig.cpu +0 -0
index 3c57033..f342a5a 100644

arch/x86/Kconfig.cpu config X86_GENERIC · line 309

Quoted 8 lines

arch/x86/Kconfig.cpu +1 -1

@@ -303,7 +303,7 @@ config X86_GENERIC
 config X86_INTERNODE_CACHE_SHIFT
 	int
 	default "12" if X86_VSMP
-	default "7" if NUMA
+	default "7" if NUMA && (MPENTIUM4)
 	default X86_L1_CACHE_SHIFT
 
 config X86_CMPXCHG

In arch/x86/include/asm/cache.h, the INTERNODE_CACHE_SHIFT macro will transfer to '__cacheline_aligned_in_smp' finally.

#ifdef CONFIG_X86_VSMP
#ifdef CONFIG_SMP

#define __cacheline_aligned_in_smp                                      \
        __attribute__((__aligned__(INTERNODE_CACHE_BYTES)))             \
        __page_aligned_data

#endif
#endif

look at the following contents in Kconfig.cpu, I wondering if it is possible to remove 'default "7" if NUMA' line. Then a thin and fit cache alignment will be potential helpful on performance.
Anyone like to give some comments?

===

arch/x86/Kconfig.cpu +0 -1

index 3c57033..6443c6f 100644
@@ -303,7 +303,6 @@ config X86_GENERIC
 config X86_INTERNODE_CACHE_SHIFT
        int
        default "12" if X86_VSMP
-       default "7" if NUMA
        default X86_L1_CACHE_SHIFT
 
 config X86_CMPXCHG

====

some contents in Kconfig.cpu:

config X86_INTERNODE_CACHE_SHIFT

        int
        default "12" if X86_VSMP
        default "7" if NUMA && (MPENTIUM4 || MPSC)
        default X86_L1_CACHE_SHIFT

config X86_CMPXCHG

        def_bool X86_64 || (X86_32 && !M386)

config X86_L1_CACHE_SHIFT

        int
        default "7" if MPENTIUM4 || MPSC
        default "6" if MK7 || MK8 || MPENTIUMM || MCORE2 || MATOM || MVIAC7 || X86_GENERIC || GENERIC_CPU
        default "4" if MELAN || M486 || M386 || MGEODEGX1
        default "5" if MWINCHIP3D || MWINCHIPC6 || MCRUSOE || MEFFICEON || MCYRIXIII || MK6 || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || M586 || MVIAC3_2 || MGEODE_LX

Quoted 1 line

Ingo Molnar

2012-03-02 08:12 UTC #2 lore raw

Quoted 26 lines · Alex Shi

Quoted 13 lines · Alex,Shi
Currently last level defined in kernel is still 128 bytes, but actually I checked intel's core2, NHM, SNB, atom, serial platforms, all of them are using 64 bytes.
I did not get detailed info on AMD platforms. Guess someone like to give the info here. So, Is if it possible to do the similar following changes to use 64 byte cache alignment in kernel?
===
arch/x86/Kconfig.cpu +0 -0
index 3c57033..f342a5a 100644
arch/x86/Kconfig.cpu config X86_GENERIC · line 309
Quoted 8 lines
arch/x86/Kconfig.cpu +1 -1
@@ -303,7 +303,7 @@ config X86_GENERIC
 config X86_INTERNODE_CACHE_SHIFT
 	int
 	default "12" if X86_VSMP
-	default "7" if NUMA
+	default "7" if NUMA && (MPENTIUM4)
 	default X86_L1_CACHE_SHIFT
 
 config X86_CMPXCHG
In arch/x86/include/asm/cache.h, the INTERNODE_CACHE_SHIFT macro will transfer to '__cacheline_aligned_in_smp' finally.

Quoted 7 lines

#ifdef CONFIG_X86_VSMP
#ifdef CONFIG_SMP

#define __cacheline_aligned_in_smp                                      \
        __attribute__((__aligned__(INTERNODE_CACHE_BYTES)))             \
        __page_aligned_data

#endif
#endif

Note the #ifdef CONFIG_X86_VSMP - so the 128 bytes does not actually transform into __cacheline_aligned_in_smp.

Quoted 10 lines

look at the following contents in Kconfig.cpu, I wondering if it is possible to remove 'default "7" if NUMA' line. Then a thin and fit cache alignment will be potential helpful on performance. Anyone like to give some comments?
config X86_INTERNODE_CACHE_SHIFT
        int
        default "12" if X86_VSMP
- default "7" if NUMA
default X86_L1_CACHE_SHIFT

Yes, removing that line would be fine I think - I think it was copied from the old L1 alignment of 128 bytes (which was a P4 artifact when that CPU was the dominant platform - that's not been the case for a long time already).

Could you please also do a before/after build of an x86 defconfig with NUMA enabled and see what the alignments in the before/after System.map are?

Thanks,

Ingo

Alex Shi

author

2012-03-02 14:43 UTC #3 lore raw

Quoted 11 lines

Quoted 8 lines
#ifdef CONFIG_X86_VSMP
#ifdef CONFIG_SMP
#define __cacheline_aligned_in_smp                                      \
        __attribute__((__aligned__(INTERNODE_CACHE_BYTES)))             \
        __page_aligned_data
#endif
#endif
Note the #ifdef CONFIG_X86_VSMP - so the 128 bytes does not actually transform into __cacheline_aligned_in_smp.

Oh, sorry, I used a inappropriate example here, actually there are lot places reference to this value, like in cscope show INTERNODE_CACHE_BYTES usages:

   1     13  arch/x86/include/asm/cache.h <<GLOBAL>>
             #define INTERNODE_CACHE_BYTES (1 << INTERNODE_CACHE_SHIFT)
   2    148  arch/x86/kernel/vmlinux.lds.S <<GLOBAL>>
             READ_MOSTLY_DATA(INTERNODE_CACHE_BYTES)
   3    190  arch/x86/kernel/vmlinux.lds.S <<GLOBAL>>
             PERCPU_VADDR(INTERNODE_CACHE_BYTES, 0, :percpu)
   4    285  arch/x86/kernel/vmlinux.lds.S <<GLOBAL>>
             PERCPU_SECTION(INTERNODE_CACHE_BYTES)
   5     48  arch/x86/mm/tlb.c <<GLOBAL>>
             char pad[INTERNODE_CACHE_BYTES];
   6     18  arch/x86/include/asm/cache.h <<__cacheline_aligned_in_smp>>
             __attribute__((__aligned__(INTERNODE_CACHE_BYTES))) \

and also many references to INTERNODE_CACHE_SHIFT,

Quoted 12 lines

Quoted 11 lines
look at the following contents in Kconfig.cpu, I wondering if it is possible to remove 'default "7" if NUMA' line. Then a thin and fit cache alignment will be potential helpful on performance. Anyone like to give some comments?
config X86_INTERNODE_CACHE_SHIFT
        int
        default "12" if X86_VSMP
- default "7" if NUMA
default X86_L1_CACHE_SHIFT

Quoted 4 lines

Yes, removing that line would be fine I think - I think it was copied from the old L1 alignment of 128 bytes (which was a P4 artifact when that CPU was the dominant platform - that's not been the case for a long time already).

Thanks! I will write a patch later.

Quoted 4 lines

Could you please also do a before/after build of an x86 defconfig with NUMA enabled and see what the alignments in the before/after System.map are?

So, with defconfig on x86_64, I saw much changes in System.map:
before patched after patched
...

  000000000000b000 d tlb_vector_|  000000000000b000 d tlb_vector
  000000000000b080 d cpu_loops_p|  000000000000b040 d cpu_loops_

...

Quoted 4 lines

Thanks,
Ingo

Ingo Molnar

2012-03-02 15:25 UTC #4 lore raw

Quoted 6 lines · Alex Shi

So, with defconfig on x86_64, I saw much changes in System.map:
before patched after patched
...
  000000000000b000 d tlb_vector_|  000000000000b000 d tlb_vector
  000000000000b080 d cpu_loops_p|  000000000000b040 d cpu_loops_
...

Ok, mind sending a patch, changelogged, with a SOB?

Thanks,

Ingo

Alex Shi

author

2012-03-03 11:31 UTC #5 lore raw

Quoted 9 lines · Ingo Molnar

Quoted 6 lines · Alex Shi
So, with defconfig on x86_64, I saw much changes in System.map:
before patched after patched
...
  000000000000b000 d tlb_vector_|  000000000000b000 d tlb_vector
  000000000000b080 d cpu_loops_p|  000000000000b040 d cpu_loops_
...
Ok, mind sending a patch, changelogged, with a SOB?

Thanks a lot for review! A patch was sent to you.

Quoted 3 lines

Thanks,
Ingo