>> I think the issue is timer_reg. What is timer_reg? To avoid a xtime_lock
>> we must make sure that the other CPU is not in the middle of the xtime
>> updating (so that only half of the xtime struct is been updated).
>
>Umm if you can write to it atomically, that solves everything.
>
>And I think I have the (x86) solution.... cmpxchg8b.
Ignoring the 486 issue...:
Does it really worth the pain? Note that in gettimeofday we need the
spinlock _anyway_ because we could race between the timer bh handler and
gettimeofday (called from an irq via get_fast_time()) (see lostticks in
sched.c and arch/i386/kernel/time.c).
And I see netif_rx() as the piece of code that play with xtime of sytem
more heavily and since for it we still need the read_write_spinlock I
don't think it worth to optimize the far less frequent get_xtime() case
(get_xtime() in my tree is a normal `2.2.2 xtime read', but protected by
the read_lock/unlock(&xtime_lock) to get a 100% sure coherent xtime
struct).
I think it would increase still more the complexity of the xtime handling
without a real benefit (and btw 2.2.2 would benefit _zero_ from such asm
cleverness, since it just bugs and doesn't use the read-spinlock around
reading xtime as I do here).
Andrea Arcangeli
-
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/