Re: [PATCH] sparc32: support atomic64_t

[Sam Ravnborg <sam@xxxxxxxxxxxx>]

On Tue, Dec 27, 2011 at 05:24:49PM -0500, David Miller wrote:
> From: David Miller <davem@xxxxxxxxxxxxx>
> Date: Tue, 27 Dec 2011 16:37:29 -0500 (EST)
> 
> > From: Sam Ravnborg <sam@xxxxxxxxxxxx>
> > Date: Tue, 27 Dec 2011 22:28:50 +0100
> > 
> >> $size vmlinux (before atomic64_t support)
> >>    text    data     bss     dec     hex filename
> >> 3578860  134260  108781 3821901  3a514d vmlinux
> >> 
> >> $size vmlinux (after atomic64_t support)
> >>    text    data     bss     dec     hex filename
> >> 3579892  130684  108781 3819357  3a475d vmlinux
> >> 
> >> text increase (3579892 - 3578860) = 1032 bytes
>  ...
> > The data decreasing is really funny indeed, it should
> > increase because of the atomic64_lock[] array in lib/atomic64.c
> > 
> > And the decrease isn't some trivial amount, it's more than 3K!
> 
> I was going to take a good look into this but I actually can't
> reproduce this with gcc-4.6.2-7 under debian.

I took a deeper look at this today - and this all boils
down to some alignment issues.

Without atomic64_t support .data had address xxx47000.
This address is nicely aligned to a page boundary.
But SPARC32 require that the thread data are aligned to a 2*PAGE_SIZE boundary,
so therefore this is rounded up to xxx48000 - thus wasting 1000=4096 bytes.

When I applied the patch to enable atomic64_t then .data got address xx48000
which is aligned to a 2*PAGE_SIZE - and no extra page wasted for alignment.

.data had a higher address because .rodata had a higher address in the atomic64_t case.
This expalins why we used less data despite using more data!

A little more details:

In the linker scripts we have:
#define RW_DATA_SECTION(cacheline, pagealigned, inittask)               \
        . = ALIGN(PAGE_SIZE);                                           \
        .data : AT(ADDR(.data) - LOAD_OFFSET) {                         \
                INIT_TASK_DATA(inittask)                                \
                NOSAVE_DATA                                             \


And we use this macro from SPARC32 like this:

	RW_DATA_SECTION(SMP_CACHE_BYTES, 0, THREAD_SIZE)

And THREAD_SIZE is defiend like this:

	#define THREAD_SIZE            8192

I should cleanup thread_info_32.h and page_32.h one day...

	Sam
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html