Andrew Morton a écrit : > > The wheel spins around, slows then settles on.... > time-smp-friendly-alignment-of-struct-clocksource.patch! > > Presumably because the ____cacheline_aligned made vsyscall_gtod_data_t get > too big. Or something. Very strange, since here I have plenty of available room (256 bytes) : ffffffffff600000 T vgettimeofday ffffffffff60004e t vsysc2 ffffffffff600140 t vread_hpet ffffffffff600150 t vread_tsc ffffffffff600180 D __vsyscall_gtod_data ffffffffff600280 D __vgetcpu_mode ffffffffff6002c0 D __jiffies ffffffffff600400 T vtime ffffffffff600413 t vsysc1 ffffffffff600800 T vgetcpu ffffffffff600c00 T venosys_1 It must depends on the compiler, and/or CONFIG_XXX options... Anyway, I think we can safely move __vgetcpu_mode & __jiffies to the 1024 bytes area dedicated to vgetcpu() implementation. This saves 128 bytes from vsyscall_0 area. Could we add this patch instead of dropping time-smp-friendly-alignment-of-struct-clocksource.patch ? Thank you [PATCH] x86_64 : move __vgetcpu_mode & __jiffies to the vsyscall_2 zone We apparently hit the 1024 limit of vsyscall_0 zone when some debugging options are set, or if __vsyscall_gtod_data is 64 bytes larger. In order to save 128 bytes from the vsyscall_0 zone, we move __vgetcpu_mode & __jiffies to vsyscall_2 zone where they really belong, since they are used only from vgetcpu() (which is in this vsyscall_2 area). After patch is applied, new layout is : ffffffffff600000 T vgettimeofday ffffffffff60004e t vsysc2 ffffffffff600140 t vread_hpet ffffffffff600150 t vread_tsc ffffffffff600180 D __vsyscall_gtod_data ffffffffff600400 T vtime ffffffffff600413 t vsysc1 ffffffffff600800 T vgetcpu ffffffffff600870 D __vgetcpu_mode ffffffffff600880 D __jiffies ffffffffff600c00 T venosys_1 Signed-off-by: Eric Dumazet