> > i'm not sure wether this will ever be accepted into the main kernel -
> > __cli()/__sti()/etc. right now is heavily used and inlined (mostly via
>
> The price is paid only if you select RTL in config.
> my idea is that system.h does
oh, ok. I thought you want to do this 'runtime', by patching a pretty
normal kernel dynamically.
> Lmbench can't detect any performance loss -- remember that cli and sti
> are not cheap instructions anyways.
they are ~7 cycles, but the real cost is the slight kernel bloat (== more
cache footprint) caused by the inlined function call. Anyway, this is of
course not a problem for an optional thing, i thought you are trying to do
this runtime as well.
> > spinlocks) and it's a single instruction. Maybe building a table of 'cli,
> > sti, popfl, pushfl' addresses into a special section can do the trick
> > without interfering with the 'normal' kernel? A single-instruction 'int 3'
> > could be patched into those places, or something like that.
>
> The "int" would cost too much in the rtl case. On
the int is basically a function call if you do it on ring 0, but yes it's
more expensive than a normal function call.
> the other hand, I had thought of
> of a section. Not sure what the advantage would be. With the structure,
> the compiler generates
>
> movel N+irq_desc,%eax
> call *%eax
if the int3 solution is implementable (it's a tough problem i think), the
advantage would be a completely unaffected 'main kernel'. RTL could be
switched on/off runtime. OTOH, people recompile kernels routinely anyway.
-- mingo
-
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/