Re: gettimeofday() a special case : why?

Eric W. Biederman (ebiederm+eric@ccr.net)
13 Dec 1999 10:34:33 -0600


Andrea Arcangeli <andrea@suse.de> writes:

> On Mon, 13 Dec 1999, David S. Miller wrote:
>
> >Well, first of all, every single network packet which arrives at or
> >leaves your system uses the guts of gettimeofday() to timestamp
> >the packet.
>
> In the tcp stack you are just inside the kernel so you don't pay the
> enter/exit cost to get the TOD information.
>
> The optimization discussed wanted to avoid the cost to enter the kernel.
>
> I think it's not possible to implement an userspace rdtsc based TOD
> without entering the kernel and without losing precision.

Dosemu does this now on single cpu systems.

> We can't acquire
> a spinlock from userspace because we can be preempted. Without the
> spinlock we can't serialize the reads of xtime and of the reference-RTSCT
> information.

gettimeofday always returns a time recently in the past.
And having an atomic variable by which keeps a generation number
for (xtime & other magic constants should be trivial).

Take one snapshot of the generation # at the start of gettimeofday,
another snapshot at the end of gettimeofday. If the snapshots
don't match take the slow path, because you've had a race.

Yes you might need an appropriate memory barrier.

> The only not racy way is to have in the readable magic kernel page a
> static xtime and rdtsc information plus the coversion constant from cycles
> to seconds. But if the conversion is not perfect we'll lose precision over
> the time...

Not the only way not racy way see above. Races are worth worrying about
but they have multiple solutions, transactions being one.

Eric

-
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/