>better kernel. (he also might thus have less social life and a tiny bit
>less happy gf - which again shows that things are relative ;)
8)8)
>hiding symptoms without fixing the real cause of the symptoms is bad.
Note that if a spinlock is held for too long time the guy is going to not
scale anyway. Also he should not rely on the spin_lock_irq as he may
need to convert the code to spin_lock_irqsave in the future.
Basically I was only thinking to improve the kernel and I didn't thought
about the possible humans-side-effects of such irq latency improvement.
My only worry was if the cli to repeat after exiting the slow path will
harm more performance than the gain of having irqs enabled. I believe
enabling irqs will pay the cost of the additional cli to run after exiting
the slow path.
If you are _only_ worried by the human-side-effect, then I can add a
#define SPIN_LOCK_SLOW on the top of spinlocks.h that will be #unset only
in 2.4.0 8).
Andrea
-
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/