[patch 1/6] align kenrel rbs on 128 byte

[patch 1/6] align kenrel rbs on 128 byte

[Chen, Kenneth W]

The bottom of kernel rbs stack is the memory used to spill user
dirty stack register partition when entering the kernel.  This
space is heavily used on every kernel entry and exit. It deserve
having its own dedicated cache line and not to share with tail
end of thread_info which is not used heavily.

Align the bottom of kernel rbs stack to 128 byte boundary.

Signed-off-by: Ken Chen <kenneth.w.chen@intel.com>


--- ./include/asm-ia64/ptrace.h.orig	2006-01-19 16:45:49.695591377 -0800
+++ ./include/asm-ia64/ptrace.h	2006-01-20 02:24:05.985205410 -0800
@@ -75,7 +75,7 @@
 # define KERNEL_STACK_SIZE_ORDER		0
 #endif
 
-#define IA64_RBS_OFFSET			((IA64_TASK_SIZE + IA64_THREAD_INFO_SIZE + 15) & ~15)
+#define IA64_RBS_OFFSET			((IA64_TASK_SIZE + IA64_THREAD_INFO_SIZE + 127) & ~127)
 #define IA64_STK_OFFSET			((1 << KERNEL_STACK_SIZE_ORDER)*PAGE_SIZE)
 
 #define KERNEL_STACK_SIZE		IA64_STK_OFFSET

Re: [patch 1/6] align kenrel rbs on 128 byte

[Keith Owens]

"Chen, Kenneth W" (on Tue, 31 Jan 2006 00:48:28 -0800) wrote:
>The bottom of kernel rbs stack is the memory used to spill user
>dirty stack register partition when entering the kernel.  This
>space is heavily used on every kernel entry and exit. It deserve
>having its own dedicated cache line and not to share with tail
>end of thread_info which is not used heavily.
>
>Align the bottom of kernel rbs stack to 128 byte boundary.
>
>Signed-off-by: Ken Chen <kenneth.w.chen@intel.com>
>
>
>--- ./include/asm-ia64/ptrace.h.orig	2006-01-19 16:45:49.695591377 -0800
>+++ ./include/asm-ia64/ptrace.h	2006-01-20 02:24:05.985205410 -0800
>@@ -75,7 +75,7 @@
> # define KERNEL_STACK_SIZE_ORDER		0
> #endif
> 
>-#define IA64_RBS_OFFSET			((IA64_TASK_SIZE + IA64_THREAD_INFO_SIZE + 15) & ~15)
>+#define IA64_RBS_OFFSET			((IA64_TASK_SIZE + IA64_THREAD_INFO_SIZE + 127) & ~127)
> #define IA64_STK_OFFSET			((1 << KERNEL_STACK_SIZE_ORDER)*PAGE_SIZE)
> 
> #define KERNEL_STACK_SIZE		IA64_STK_OFFSET

The cache lines are not guaranteed to be 128 byte aligned, they were 64
on bigsur.  Change 127 to (L1_CACHE_BYTES - 1).

RE: [patch 1/6] align kenrel rbs on 128 byte

[Chen, Kenneth W]

Keith Owens wrote on Tuesday, January 31, 2006 12:57 AM
> "Chen, Kenneth W" (on Tue, 31 Jan 2006 00:48:28 -0800) wrote:
> >The bottom of kernel rbs stack is the memory used to spill user
> >dirty stack register partition when entering the kernel.  This
> >space is heavily used on every kernel entry and exit. It deserve
> >having its own dedicated cache line and not to share with tail
> >end of thread_info which is not used heavily.
> >
> >Align the bottom of kernel rbs stack to 128 byte boundary.
> >
> >Signed-off-by: Ken Chen <kenneth.w.chen@intel.com>
> >
> 
> The cache lines are not guaranteed to be 128 byte aligned, they
> were 64 on bigsur.  Change 127 to (L1_CACHE_BYTES - 1).

That did cross my mind and L1_CACHE_BYTES is such a misleading
name.  In my head, L1 means the cache level closest to the CPU
core, but here it appears to represent last level cache line.
Do we have the numbering scheme reversed?  I have no idea what's
going on here. 

- Ken

p.s. It's amazing people is still using bigsur. Long live Itanium!

Re: [patch 1/6] align kenrel rbs on 128 byte

[Andreas Schwab]

Keith Owens <kaos@sgi.com> writes:

> The cache lines are not guaranteed to be 128 byte aligned, they were 64
> on bigsur.

A 128 byte aligned address is also 64 byte aligned.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [patch 1/6] align kenrel rbs on 128 byte

[Jes Sorensen]

>>>>> "Ken" = Chen, Kenneth W <kenneth.w.chen@intel.com> writes:

Ken> Keith Owens wrote on Tuesday, January 31, 2006 12:57 AM
>> The cache lines are not guaranteed to be 128 byte aligned, they
>> were 64 on bigsur.  Change 127 to (L1_CACHE_BYTES - 1).

Ken> That did cross my mind and L1_CACHE_BYTES is such a misleading
Ken> name.  In my head, L1 means the cache level closest to the CPU
Ken> core, but here it appears to represent last level cache line.  Do
Ken> we have the numbering scheme reversed?  I have no idea what's
Ken> going on here.

Ken,

Shouldn't this be SMP_CACHE_BYTES if anything?

Cheers,
Jes

Re: [patch 1/6] align kenrel rbs on 128 byte

[Russ Anderson]

Kenneth Chen wrote:
> Keith Owens wrote on Tuesday, January 31, 2006 12:57 AM
> > 
> > The cache lines are not guaranteed to be 128 byte aligned, they
> > were 64 on bigsur.  Change 127 to (L1_CACHE_BYTES - 1).
> 
> That did cross my mind and L1_CACHE_BYTES is such a misleading
> name.  In my head, L1 means the cache level closest to the CPU
> core, but here it appears to represent last level cache line.
> Do we have the numbering scheme reversed?  I have no idea what's
> going on here. 

I agree that L1_CACHE_BYTES is misleading.  Looking at
the usage, most (if not all) references expect the 
last (external/FSB) cache line size, not caches closer
to the core.  As Jes points out SMP_CACHE_BYTES is
more what they mean.

Why not just call it CACHE_BYTES, meaning the last cache
level.  Handling of caches closer to the core most likely
should be through PAL, or, it really needed, use the 
engineering cache level prefix.

-- 
Russ Anderson, OS RAS/Partitioning Project Lead  
SGI - Silicon Graphics Inc          rja@sgi.com

RE: [patch 1/6] align kenrel rbs on 128 byte

[Chen, Kenneth W]

Jes Sorensen wrote on Tuesday, January 31, 2006 3:01 AM
> Ken> Keith Owens wrote on Tuesday, January 31, 2006 12:57 AM
> >> The cache lines are not guaranteed to be 128 byte aligned, they
> >> were 64 on bigsur.  Change 127 to (L1_CACHE_BYTES - 1).
> 
> Ken> That did cross my mind and L1_CACHE_BYTES is such a misleading
> Ken> name.  In my head, L1 means the cache level closest to the CPU
> Ken> core, but here it appears to represent last level cache line.  Do
> Ken> we have the numbering scheme reversed?  I have no idea what's
> Ken> going on here.
> 
> Shouldn't this be SMP_CACHE_BYTES if anything?


Yeah, if nobody cares about UP performance. SMP_CACHE_BYTES is 8 bytes
on UP kernel (though it doesn't seem that anyone cares about UP).  I
will consult Tony to see what he likes.  I might settle with
L1_CACHE_BYTES.  I can just see people is going yell at me for having
125 column line :-p  :-))

- Ken

Re: [patch 1/6] align kenrel rbs on 128 byte

[Richard Harke]

On Tue January 31 2006 08:25, Chen, Kenneth W wrote:

.
.
.>
> Yeah, if nobody cares about UP performance. SMP_CACHE_BYTES is 8 bytes
> on UP kernel (though it doesn't seem that anyone cares about UP).  I
Well, I care about UP. But HP, Intel and SGI have made it pretty clear
they don't care about UP (or the customers that have UP machines)
> will consult Tony to see what he likes.  I might settle with
> L1_CACHE_BYTES.  I can just see people is going yell at me for having
> 125 column line :-p  :-))
>
> - Ken
>
> -

RE: [patch 1/6] align kenrel rbs on 128 byte

[Chen, Kenneth W]

Richard Harke wrote on Tuesday, January 31, 2006 11:59 AM
> > Yeah, if nobody cares about UP performance. SMP_CACHE_BYTES is 8 bytes
> > on UP kernel (though it doesn't seem that anyone cares about UP).  I
> 
> Well, I care about UP. But HP, Intel and SGI have made it pretty clear
> they don't care about UP (or the customers that have UP machines)

I heard you.  L1_CACHE_BYTES it is, so everyone can be benefited from
the change: merced processor, UP, SMP you name it.

- Ken

Re: [patch 1/6] align kenrel rbs on 128 byte

[Richard Harke]

On Tue January 31 2006 11:59, Chen, Kenneth W wrote:
> Richard Harke wrote on Tuesday, January 31, 2006 11:59 AM
>
> > > Yeah, if nobody cares about UP performance. SMP_CACHE_BYTES is 8 bytes
> > > on UP kernel (though it doesn't seem that anyone cares about UP).  I
> >
> > Well, I care about UP. But HP, Intel and SGI have made it pretty clear
> > they don't care about UP (or the customers that have UP machines)
>
> I heard you.  L1_CACHE_BYTES it is, so everyone can be benefited from
> the change: merced processor, UP, SMP you name it.
>
> - Ken
Thanks

Richard