Re: [block IO crash] Re: 2.6.39-rc5-git2 boot crashs

[Thomas Gleixner <tglx@linutronix.de>]

On Thu, 5 May 2011, Tejun Heo wrote:
> 2. Make irq toggling as cheap as preemption toggling.  This can be
>    achieved by implementing IRQ masking in software.  I played with it
>    a bit on x86 last year.  I didn't get to finish it and it would
>    have taken me some time to iron out weird failures but it didn't
>    seem too difficult and as irq on/off is quite expensive on a lot of
>    CPUs, this might bring overall performance benefit.
> 
> For many archs, #2 would be the only choice and if we're gonna do that
> I think it would be best to do it on x86 too.  It involves changes to
> common code too and x86 has the highest test/development coverage.
> 
> I don't feel brave enough to remove preemption protected ones without
> first somehow taking care of non-x86 archs.  The preemption disabled
> ones are used for statistics in net, block, irq and fs and simply
> switching to irq protected ones is likely to noticeably hurt many
> non-x86 archs.  Maybe the ones which really matter can implement at
> least _add() and we can get away without doing soft irq masking.

There it's fine when we have certain use cases which just need
preemption protection, but the function name should be clear about it
and we should only have the functions which are actually required
instead of every possible flavour of _OP.
 
> Anyways, that's what I've been thinking.  I'll get to it in the next
> devel cycle or the one after that.  What do you guys think about soft
> irq masking idea?

It's doable, we played around with that in rt already and put it aside
again :)

You need to do the check at the vector entry and then reinject the
vector on local_irq_enable/restore(), so that's mostly hackery in the
ASM entry code which includes to fixup the pushed flags so the reti
wont reeneable interrupts.

That's halfways easy to do on x86, not sure about other architectures,
and you have to carefully weigh the actual benefit against the
overhead in the slow path case plus the inevitable hackery you need in
each architecture implementation.

No strong opinion, but definitely worthwhile to toy with it :)

Thanks,

	tglx