Messages in this thread | | | Date | Tue, 26 Jun 2007 02:00:47 -0700 | From | Andrew Morton <> | Subject | Re: [patch] CFS scheduler, -v18 |
| |
On Tue, 26 Jun 2007 10:38:13 +0200 Ingo Molnar <mingo@elte.hu> 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |