Messages in this thread | | | Subject | Re: gettimeofday() a special case : why? | From | (Eric W. Biederman) | Date | 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/
| |