[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070626093823.GA9850@elte.hu>
Date: Tue, 26 Jun 2007 11:38:23 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: "S.??a??lar Onur" <caglar@...dus.org.tr>,
linux-kernel@...r.kernel.org,
Linus Torvalds <torvalds@...ux-foundation.org>,
Mike Galbraith <efault@....de>,
Arjan van de Ven <arjan@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>,
Dmitry Adamushko <dmitry.adamushko@...il.com>,
Srivatsa Vaddagiri <vatsa@...ux.vnet.ibm.com>
Subject: Re: [patch] CFS scheduler, -v18
* Andrew Morton <akpm@...ux-foundation.org> wrote:
> > the main reason is the sched debugging stuff:
>
> That would serve to explain the 18% growth on x86_64. But why did
> i386 grow by much more: 29%? I'd be suspecting all the new 64-bit
> arithmetic.
this is what i see on 32-bit:
text data bss dec hex filename
28732 3905 24 32661 7f95 kernel/sched.o-vanilla
37986 2538 20 40544 9e60 kernel/sched.o-v18
31092 2426 20 33538 8302 kernel/sched.o-v18-no_sched_debug
text is larger but data got smaller. While they are not equivalent in
function, the two almost even out each other (and that's without any of
the uninlining that is in v19). In fact, there's a 1.5K per CPU percpu
data size win with CFS, which is not visible in this stat. So on
dual-core the net cost should already be zero.
> The cost on 32-bit appears to be pretty high. Perhaps a round of
> uninlining will help.
agreed, i've done one more round of uninlining.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists