On Tue, 26 Jun 2007 10:38:13 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > > - __exit_signal() does apparently-unlocked 64-bit arith. Is there > > some implicit locking here or do we not care about the occasional > > race-induced inaccuracy? > > do you mean the tsk->se.sum_exec_runtime addition, etc? That runs with > interrupts disabled so sum_sched_runtime is protected. > > > (ditto, lots of places, I expect) > > which places do you mean? I forget ;) There seemed to be rather a lot of 64-bit addition with no obvious locking in sight, that's all. > > ... > > (Gee, there's shitloads of 64-bit stuff in there. Does it all > > _really_ need to be 64-bit on 32-bit?) > > yes - CFS is fundamentally designed for 64-bit, with still pretty OK > arithmetics performance for 32-bit. It may have been designed for 64-bit, but was that the correct design? The cost on 32-bit appears to be pretty high. Perhaps a round of uninlining will help. > > - overall, CFS takes sched.o from 41157 of .text up to 48781 on x86_64, > > which at 18% is rather a large bloat. Hopefully a lot of this is > > the new debug stuff. > > > - On i386 sched.o went from 33755 up to 43660 which is 29% growth. > > Possibly acceptable, but why did it increase a lot more than the x86_64 > > version? All that 64-bit arith, I assume? > > 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
