Re: [patch] smptimers, old BH removal, tq-cleanup, 2.5.39

[george anzinger <george@mvista.com>]

Ingo Molnar wrote:
> 
> On Mon, 30 Sep 2002, David S. Miller wrote:
> 
> > I did some thinking, and I don't understand how this old code can be
> > legal.  Doesn't this make do_gettimeofday() inaccurate?
> 
> it's a mostly bogus comment, dont think about it too much.
> 
>         Ingo
Actually gettimeofday is fine.  It does not depend on the
timer interrupt, but only on one happening every once in a
while.  It make up any latency by using the TSC and time of
last interrupt and is in no way dependent on any latency in
the run_timer_list.

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