By the way, I have been lately impressed with the relative
amount of time a cli/sti takes and have wondered if we might
not get a "nice" improvement in system performance by moving
the xtime read/write lock from an irq to a bh lock. This
would avoid the cli/sti in the read lock which is needed to
read the time. All this should take (aside from finding all
the locks) is to move the write access of xtime to the bh
code. Since it does nothing if timer_jiffie == jiffie, it
does not hurt to call it from each cpu. The timer interrupt
would then bump a shadow jiffie which would not appear in
jiffies until the bh code runs.
On finding the locks, I suggest abstracting them to a macro,
thus allowing the change to be made only one place. Of
course, we need to change the name of the lock to enlist the
compilers help in finding them. But then if we are sure
this is the way to go, there is no need for the macro.
-- George Anzinger george@mvista.com High-res-timers: http://sourceforge.net/projects/high-res-timers/ Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml - 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/