Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*do_gettimeofday\s*$/: 24 ]

Total 24 documents matching your query.

21. Re: do_gettimeofday (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxx>
Date: Fri, 3 Oct 2003 01:52:20 -0700
Right, that would work. There is the weird issue (with both the sparc64 example and your's here) of whether we should care about what happens when settimeofday() occurs. We probably shouldn't worry a
/archives/netdev/2003-10/msg00813.html (10,472 bytes)

22. Re: do_gettimeofday (score: 1)
Author: Mitchell Blank Jr <mitch@xxxxxxxxxx>
Date: Fri, 3 Oct 2003 02:26:17 -0700
Nah. If anything you'll get better results since you're computing the timeval later. This is another argument for caching the computation though - otherwise a settimeofday() could cause the packet ti
/archives/netdev/2003-10/msg00814.html (10,758 bytes)

23. Re: do_gettimeofday (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxx>
Date: Fri, 3 Oct 2003 02:23:38 -0700
Well, it's is the fact that usage of the timestamp is rare which we're trying to take advantage of. The whole idea is that fast_timestamp_to_timeval() can be a bit slow or suboptimal in order to make
/archives/netdev/2003-10/msg00815.html (9,591 bytes)

24. Re: do_gettimeofday (score: 1)
Author: Ben Greear <greearb@xxxxxxxxxxxxxxx>
Date: Fri, 03 Oct 2003 09:42:19 -0700
There is the weird issue (with both the sparc64 example and your's here) of whether we should care about what happens when settimeofday() occurs. We probably shouldn't worry about it... as it gives
/archives/netdev/2003-10/msg00832.html (10,805 bytes)


This search system is powered by Namazu