readmostly section should end at cache line aligned address, otherwise the last
several data might share cachline with other data and make the readmostly data
still have cache bounce.
For example, in ia64, secpath_cachep is the last readmostly data, and it shares
cacheline with init_uts_ns.
a000000100e80480 d secpath_cachep
a000000100e80488 D init_uts_ns
Signed-off-by: Shaohua Li <[email protected]>
---
include/asm-generic/vmlinux.lds.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: linux/include/asm-generic/vmlinux.lds.h
===================================================================
--- linux.orig/include/asm-generic/vmlinux.lds.h 2010-12-01 16:49:48.000000000 +0800
+++ linux/include/asm-generic/vmlinux.lds.h 2010-12-02 09:22:32.000000000 +0800
@@ -192,7 +192,8 @@
#define READ_MOSTLY_DATA(align) \
. = ALIGN(align); \
- *(.data..read_mostly)
+ *(.data..read_mostly) \
+ . = ALIGN(align);
#define CACHELINE_ALIGNED_DATA(align) \
. = ALIGN(align); \
On Thu, 02 Dec 2010 10:02:21 +0800 Shaohua Li <[email protected]> wrote:
> readmostly section should end at cache line aligned address, otherwise the last
> several data might share cachline with other data and make the readmostly data
> still have cache bounce.
> For example, in ia64, secpath_cachep is the last readmostly data, and it shares
> cacheline with init_uts_ns.
> a000000100e80480 d secpath_cachep
> a000000100e80488 D init_uts_ns
>
> Signed-off-by: Shaohua Li <[email protected]>
>
> ---
> include/asm-generic/vmlinux.lds.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> Index: linux/include/asm-generic/vmlinux.lds.h
> ===================================================================
> --- linux.orig/include/asm-generic/vmlinux.lds.h 2010-12-01 16:49:48.000000000 +0800
> +++ linux/include/asm-generic/vmlinux.lds.h 2010-12-02 09:22:32.000000000 +0800
> @@ -192,7 +192,8 @@
>
> #define READ_MOSTLY_DATA(align) \
> . = ALIGN(align); \
> - *(.data..read_mostly)
> + *(.data..read_mostly) \
> + . = ALIGN(align);
>
> #define CACHELINE_ALIGNED_DATA(align) \
> . = ALIGN(align); \
>
Surely the sane way to do this is to ensure that each section *starts*
at an at-least-cacheline aligned address and then not worry about how
the section ends. So shouldn't we be fixing DATA_DATA?
With your approach, .data may end up sharing a cacheline with
some other section in some undesirable manner on a different arch.
"fixing" DATA_DATA would involve page-aligning it, which sucks a bit.
Things would be better if include/asm-generic/vmlinux.lds.h had access
to a globally-agreed cacheline-size, as it does the page size.
otoh, .data.read_mostly is "special", in that it wants the tail end of
its last cacheline not to share with any other section. Most other
sections aren't like that.
On Thu, 2010-12-02 at 10:28 +0800, Andrew Morton wrote:
> On Thu, 02 Dec 2010 10:02:21 +0800 Shaohua Li <[email protected]> wrote:
>
> > readmostly section should end at cache line aligned address, otherwise the last
> > several data might share cachline with other data and make the readmostly data
> > still have cache bounce.
> > For example, in ia64, secpath_cachep is the last readmostly data, and it shares
> > cacheline with init_uts_ns.
> > a000000100e80480 d secpath_cachep
> > a000000100e80488 D init_uts_ns
> >
> > Signed-off-by: Shaohua Li <[email protected]>
> >
> > ---
> > include/asm-generic/vmlinux.lds.h | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > Index: linux/include/asm-generic/vmlinux.lds.h
> > ===================================================================
> > --- linux.orig/include/asm-generic/vmlinux.lds.h 2010-12-01 16:49:48.000000000 +0800
> > +++ linux/include/asm-generic/vmlinux.lds.h 2010-12-02 09:22:32.000000000 +0800
> > @@ -192,7 +192,8 @@
> >
> > #define READ_MOSTLY_DATA(align) \
> > . = ALIGN(align); \
> > - *(.data..read_mostly)
> > + *(.data..read_mostly) \
> > + . = ALIGN(align);
> >
> > #define CACHELINE_ALIGNED_DATA(align) \
> > . = ALIGN(align); \
> >
>
> Surely the sane way to do this is to ensure that each section *starts*
> at an at-least-cacheline aligned address and then not worry about how
> the section ends. So shouldn't we be fixing DATA_DATA?
Some archs don't use DATA_DATA but directly use READ_MOSTLY_DATA, so I
change READ_MOSTLY_DATA.
> With your approach, .data may end up sharing a cacheline with
> some other section in some undesirable manner on a different arch.
>
> "fixing" DATA_DATA would involve page-aligning it, which sucks a bit.
> Things would be better if include/asm-generic/vmlinux.lds.h had access
> to a globally-agreed cacheline-size, as it does the page size.
yes, there isn't a well defined cacheline-size for vmlinux.lds.h.
> otoh, .data.read_mostly is "special", in that it wants the tail end of
> its last cacheline not to share with any other section. Most other
> sections aren't like that.
yes, other sections don't need to be so.
Thanks,
Shaohua