Re: [RFC] exit_thread() speedups in x86 process.c

Re: [RFC] exit_thread() speedups in x86 process.c

[Chuck Ebbert]

On Wed, 22 Jun 2005 at 04:41:47 -0400, cutaway wrote:

> The compilers got tweaked to be able to emit
> function code to different text sections and a massive system wide code
> triage was undertaken based on "common usage scenario" profiling run data
> from the perf analysis group.

  Linux scheduler code is in its own text section already, but
that might be for profiling the code instead of for performance.
(Look for "__sched" in the source code.)

  The gains may not be as much as you think since on X86 and at least
some other archs the entire kernel is in one large page.  Still, it's
got to make some kind of sense to put infrequently-used code in its
own section just to reduce cache pollution.

  I came up with this but only the "__slow" part really makes sense:


--- 2.6.12.1/arch/i386/kernel/vmlinux.lds.S     2004-09-03 19:55:27.000000000 -0400
+++ 2.6.12.1-ce1/arch/i386/kernel/vmlinux.lds.S 2005-06-26 01:48:23.770212000 -0400
@@ -16,9 +16,11 @@ SECTIONS
   /* read-only */
   _text = .;                   /* Text and read-only data */
   .text : {
+       *(.fast.text)
        *(.text)
        SCHED_TEXT
        LOCK_TEXT
+       *(.slow.text)
        *(.fixup)
        *(.gnu.warning)
        } = 0x9090
--- 2.6.12.1/arch/x86_64/kernel/vmlinux.lds.S   2005-06-24 00:50:21.180212000 -0400
+++ 2.6.12.1-ce1/arch/x86_64/kernel/vmlinux.lds.S       2005-06-26 01:50:09.100212000 -0400
@@ -15,9 +15,11 @@ SECTIONS
   phys_startup_64 = startup_64 - LOAD_OFFSET;
   _text = .;                   /* Text and read-only data */
   .text : {
+       *(.fast.text)
        *(.text)
        SCHED_TEXT
        LOCK_TEXT
+       *(.slow.text)
        *(.fixup)
        *(.gnu.warning)
        } = 0x9090
--- 2.6.12.1/include/linux/init.h       2005-01-04 21:48:02.000000000 -0500
+++ 2.6.12.1-ce1/include/linux/init.h   2005-06-26 01:59:29.580212000 -0400
@@ -46,6 +46,17 @@
 #define __exitdata     __attribute__ ((__section__(".exit.data")))
 #define __exit_call    __attribute_used__ __attribute__ ((__section__ (".exitcall.exit")))
 
+/*
+ * Probably belongs in some other header (compiler.h?)
+ */
+#ifdef CONFIG_X86
+#define __fast         __attribute__ ((__section__(".fast.text")))
+#define __slow         __attribute__ ((__section__(".slow.text")))
+#else
+#define __fast
+#define __slow
+#endif
+
 #ifdef MODULE
 #define __exit         __attribute__ ((__section__(".exit.text")))
 #else

--
Chuck

Re: [RFC] exit_thread() speedups in x86 process.c

[Denis Vlasenko]

On Saturday 02 July 2005 05:57, Chuck Ebbert wrote:
> On Wed, 22 Jun 2005 at 04:41:47 -0400, cutaway wrote:
> 
> > The compilers got tweaked to be able to emit
> > function code to different text sections and a massive system wide code
> > triage was undertaken based on "common usage scenario" profiling run data
> > from the perf analysis group.
> 
>   Linux scheduler code is in its own text section already, but
> that might be for profiling the code instead of for performance.
> (Look for "__sched" in the source code.)
> 
>   The gains may not be as much as you think since on X86 and at least
> some other archs the entire kernel is in one large page.  Still, it's
> got to make some kind of sense to put infrequently-used code in its
> own section just to reduce cache pollution.
> 
>   I came up with this

Nice.

> but only the "__slow" part really makes sense:

80/20 rule says that 80% of code runs 20% of time,
thus we need only __fast. Everything else will be by default __slow.
(IOW: normal .text section is __slow, no need to add another one).

If gcc will someday get per-function support for using -O2 / -Os
like optimizations, they could be added to the __fast macro.

> --- 2.6.12.1/arch/i386/kernel/vmlinux.lds.S     2004-09-03 19:55:27.000000000 -0400
> +++ 2.6.12.1-ce1/arch/i386/kernel/vmlinux.lds.S 2005-06-26 01:48:23.770212000 -0400
> @@ -16,9 +16,11 @@ SECTIONS
>    /* read-only */
>    _text = .;                   /* Text and read-only data */
>    .text : {
> +       *(.fast.text)
>         *(.text)
>         SCHED_TEXT
>         LOCK_TEXT
> +       *(.slow.text)
>         *(.fixup)
>         *(.gnu.warning)
>         } = 0x9090
> --- 2.6.12.1/arch/x86_64/kernel/vmlinux.lds.S   2005-06-24 00:50:21.180212000 -0400
> +++ 2.6.12.1-ce1/arch/x86_64/kernel/vmlinux.lds.S       2005-06-26 01:50:09.100212000 -0400
> @@ -15,9 +15,11 @@ SECTIONS
>    phys_startup_64 = startup_64 - LOAD_OFFSET;
>    _text = .;                   /* Text and read-only data */
>    .text : {
> +       *(.fast.text)
>         *(.text)
>         SCHED_TEXT
>         LOCK_TEXT
> +       *(.slow.text)
>         *(.fixup)
>         *(.gnu.warning)
>         } = 0x9090
> --- 2.6.12.1/include/linux/init.h       2005-01-04 21:48:02.000000000 -0500
> +++ 2.6.12.1-ce1/include/linux/init.h   2005-06-26 01:59:29.580212000 -0400
> @@ -46,6 +46,17 @@
>  #define __exitdata     __attribute__ ((__section__(".exit.data")))
>  #define __exit_call    __attribute_used__ __attribute__ ((__section__ (".exitcall.exit")))
>  
> +/*
> + * Probably belongs in some other header (compiler.h?)
> + */
> +#ifdef CONFIG_X86
> +#define __fast         __attribute__ ((__section__(".fast.text")))
> +#define __slow         __attribute__ ((__section__(".slow.text")))
> +#else
> +#define __fast
> +#define __slow
> +#endif
> +
>  #ifdef MODULE
>  #define __exit         __attribute__ ((__section__(".exit.text")))
>  #else
--
vda

function ordering (was: Re: [RFC] exit_thread() speedups in x86 process.c)

[Arjan van de Ven]

On Sat, 2005-07-02 at 14:56 +0300, Denis Vlasenko wrote:
> On Saturday 02 July 2005 05:57, Chuck Ebbert wrote:
> > On Wed, 22 Jun 2005 at 04:41:47 -0400, cutaway wrote:
> > 
> > > The compilers got tweaked to be able to emit
> > > function code to different text sections and a massive system wide code
> > > triage was undertaken based on "common usage scenario" profiling run data
> > > from the perf analysis group.
> > 
> >   Linux scheduler code is in its own text section already, but
> > that might be for profiling the code instead of for performance.
> > (Look for "__sched" in the source code.)
> > 
> >   The gains may not be as much as you think since on X86 and at least
> > some other archs the entire kernel is in one large page.  Still, it's
> > got to make some kind of sense to put infrequently-used code in its
> > own section just to reduce cache pollution.
> > 
> >   I came up with this
> 
> Nice.
> 
> > but only the "__slow" part really makes sense:


hmm. I wonder if a slightly different approach (based on the __slow)
idea would make sense
1) Use -ffunction-sections option from gcc to put each function in it's
own section
2) Use readprofile/oprofile data to collect an (external to the code)
list of hot/cold functions (we can put a default list in the kernel
source somewhere and allow people to measure their own if they want)
3) Use this list to make a linker script to order the functions

this way we don't need to put a lot of __slow's in the code *and* it's
based on measurements not assumptions, and can be tuned for a specific
situation in addition.

Re: function ordering (was: Re: [RFC] exit_thread() speedups in x86 process.c)

[Hugh Dickins]

On Sun, 3 Jul 2005, Arjan van de Ven wrote:
> 
> hmm. I wonder if a slightly different approach (based on the __slow)
> idea would make sense
> 1) Use -ffunction-sections option from gcc to put each function in it's
> own section
> 2) Use readprofile/oprofile data to collect an (external to the code)
> list of hot/cold functions (we can put a default list in the kernel
> source somewhere and allow people to measure their own if they want)
> 3) Use this list to make a linker script to order the functions
> 
> this way we don't need to put a lot of __slow's in the code *and* it's
> based on measurements not assumptions, and can be tuned for a specific
> situation in addition.

This is reminiscent of "fur", whose source Old SCO opened.
Google for SCO fur: amidst all the hits about "fur flying"
you might find something useful!

Hugh

Re: function ordering (was: Re: [RFC] exit_thread() speedups in x86 process.c)

[Arjan van de Ven]

On Sun, 2005-07-03 at 13:30 +0100, Hugh Dickins wrote:
> On Sun, 3 Jul 2005, Arjan van de Ven wrote:
> > 
> > hmm. I wonder if a slightly different approach (based on the __slow)
> > idea would make sense
> > 1) Use -ffunction-sections option from gcc to put each function in it's
> > own section
> > 2) Use readprofile/oprofile data to collect an (external to the code)
> > list of hot/cold functions (we can put a default list in the kernel
> > source somewhere and allow people to measure their own if they want)
> > 3) Use this list to make a linker script to order the functions
> > 
> > this way we don't need to put a lot of __slow's in the code *and* it's
> > based on measurements not assumptions, and can be tuned for a specific
> > situation in addition.
> 
> This is reminiscent of "fur", whose source Old SCO opened.
> Google for SCO fur: amidst all the hits about "fur flying"
> you might find something useful!

it's also similar to the idea to Nat's grope ;)
it's just a lot easier for the kernel than for the average userspace
since we already have linker scripts

Re: [RFC] exit_thread() speedups in x86 process.c

[cutaway]

----- Original Message ----- 
From: "Denis Vlasenko" <vda@ilport.com.ua>
To: "Chuck Ebbert" <76306.1226@compuserve.com>; <cutaway@bellsouth.net>
Cc: "linux-kernel" <linux-kernel@vger.kernel.org>; "Coywolf Qi Hunt"
<coywolf@gmail.com>
Sent: Saturday, July 02, 2005 07:56
Subject: Re: [RFC] exit_thread() speedups in x86 process.c


>
> 80/20 rule says that 80% of code runs 20% of time,
> thus we need only __fast. Everything else will be by default __slow.
> (IOW: normal .text section is __slow, no need to add another one).

What makes you think __fast implies everything else should necessarily be
"slow"?

You might want to entertain the idea that some systems employ several
different speeds of memory where the penalty for making such assumptions
could be extreme if the bootstrap were to metric available memory regions
for response and locate portions of the system accordingly someday.

Re: function ordering (was: Re: [RFC] exit_thread() speedups in x86 process.c)

[Christoph Hellwig]

On Sun, Jul 03, 2005 at 01:30:23PM +0100, Hugh Dickins wrote:
> > this way we don't need to put a lot of __slow's in the code *and* it's
> > based on measurements not assumptions, and can be tuned for a specific
> > situation in addition.
> 
> This is reminiscent of "fur", whose source Old SCO opened.
> Google for SCO fur: amidst all the hits about "fur flying"
> you might find something useful!

Was it?  I was at Scaldera back in the days when it was supposed to get
opensourced, but AFAIK it never actually happened, everyone just talked
about it.

Re: function ordering (was: Re: [RFC] exit_thread() speedups in x86 process.c)

[Hugh Dickins]

On Mon, 4 Jul 2005, Christoph Hellwig wrote:
> On Sun, Jul 03, 2005 at 01:30:23PM +0100, Hugh Dickins wrote:
> > > this way we don't need to put a lot of __slow's in the code *and* it's
> > > based on measurements not assumptions, and can be tuned for a specific
> > > situation in addition.
> > 
> > This is reminiscent of "fur", whose source Old SCO opened.
> > Google for SCO fur: amidst all the hits about "fur flying"
> > you might find something useful!
> 
> Was it?  I was at Scaldera back in the days when it was supposed to get
> opensourced, but AFAIK it never actually happened, everyone just talked
> about it.

Look like you're right.  Google shows me an announcement of intent,
and a man page, and an interesting gcc discussion; but no fur source.

Hugh