Re: [OT]Re: question about kernel/sched.c - 2.2.10

Richard B. Johnson (root@chaos.analogic.com)
Tue, 29 Jun 1999 11:11:59 -0400 (EDT)


On Mon, 28 Jun 1999, brent verner wrote:

>
> > This is becoming a FAQ.
>
> sorry :-(
>
> > Generally, in some code that is speed-critical, one would like to
> > have the main path through the code (the fast path), execute with
> > no jumps that could force the CPU instruction cache to be refilled.
> >
> > So you would like something like:
> >
> > if(abnormal_condition == TRUE) goto quit;
> > fast_path();
> > fast_path();
> > quit:;
> >
>
> yes this makes sense. it's like a bypass...
>
> > if(a) {
> > if(b) {
> > if(c) {
> > if(d) {
> > if(error) goto quit;
> >
>
> and this, like a shortcut....
>
> but, the following seems to me, like a detour...
>
> if (bh_mask & bh_active)
> goto handle_bh;
> handle_bh_back:
> .........
>
> handle_bh:
> do_bottom_half();
> goto handle_bh_back;
>
>
> this is what appears is schedule(). i compiled this to asm,
> and saw that this adds two 'jmp's and two '.p2align's
>
> `gcc -O2 -S original_sched.c`
> ------

You must use the same command-line parameters as the kernel compile,
as well as the -S.

Then, if you think you can make the fast path faster, you can time
it and, if correct, submit a patch.

Cheers,
Dick Johnson
***** FILE SYSTEM WAS MODIFIED *****
Penguin : Linux version 2.2.6 on an i686 machine (400.59 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/