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.

1. do_gettimeofday (score: 1)
Author: Steve Modica <modica@xxxxxxx>
Date: Thu, 02 Oct 2003 13:32:27 -0500
We've been doing some experiments here with large numbers of adapters on a 64p Linux system. When running 8 threads and 8 cpus, the do_gettimeofday code starts to use a lot of time. It turns out that
/archives/netdev/2003-10/msg00032.html (9,492 bytes)

2. Re: do_gettimeofday (score: 1)
Author: Andi Kleen <ak@xxxxxxx>
Date: Thu, 2 Oct 2003 21:29:42 +0200
That's a known problem. The funny thing is that the only users of this time stamp is SO_TIMESTAMP, which is rarely used (except tcpdump) and something in DECnet. IMHO the right fix is to add a global
/archives/netdev/2003-10/msg00036.html (8,581 bytes)

3. Re: do_gettimeofday (score: 1)
Author: Stephen Hemminger <shemminger@xxxxxxxx>
Date: Thu, 2 Oct 2003 12:56:25 -0700
Two problems: a. xtime is limited to HZ resolution which is insufficient for more advanced packet schedulers and rtt estimation. b. unlocked access to xtime is unsafe because it is not atomic! ATM is
/archives/netdev/2003-10/msg00037.html (10,667 bytes)

4. Re: do_gettimeofday (score: 1)
Author: Mitchell Blank Jr <mitch@xxxxxxxxxx>
Date: Thu, 2 Oct 2003 13:46:36 -0700
It got fixed in 2.5 (when skb->stamp got changed to nanosecond resolution so it broke the compile to do it the old way) You can use LXR to see all of the xtime users as of 2.6.0-test2: http://lxr.lin
/archives/netdev/2003-10/msg00038.html (9,182 bytes)

5. Re: do_gettimeofday (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxx>
Date: Fri, 3 Oct 2003 00:41:33 -0700
Yes, this issue is well known and it gets brought up again from time to time. And it's by no means just SO_TIMESTAMP that uses the skb->stamp values, even IPV4/IPV6 fragmentation uses these things. T
/archives/netdev/2003-10/msg00067.html (11,204 bytes)

6. Re: do_gettimeofday (score: 1)
Author: Mitchell Blank Jr <mitch@xxxxxxxxxx>
Date: Fri, 3 Oct 2003 01:26:42 -0700
Are there any common cases where skb->stamp is looked at more than once? If so I might recommend changing the API to be more like: const struct timeval *skb_timestamp(struct skbuff *skb); where the g
/archives/netdev/2003-10/msg00068.html (10,805 bytes)

7. Re: do_gettimeofday (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxx>
Date: Fri, 3 Oct 2003 01:27:54 -0700
Yes, the packet scheduler can cause this to happen. Please no, making this a SKB or networking specific interface make it nearly valueless and we might as well just stay with the stuff we have. Doesn
/archives/netdev/2003-10/msg00069.html (9,449 bytes)

8. Re: do_gettimeofday (score: 1)
Author: Mitchell Blank Jr <mitch@xxxxxxxxxx>
Date: Fri, 3 Oct 2003 01:48:47 -0700
That's definately the worst case. You could have each CPU periodically store its current {tsc,timeval} tuple in a per-cpu location and extrapolate from that. It all depends on what percentage of skb'
/archives/netdev/2003-10/msg00070.html (9,300 bytes)

9. 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/msg00071.html (10,242 bytes)

10. 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/msg00072.html (10,484 bytes)

11. 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/msg00073.html (9,294 bytes)

12. Re: do_gettimeofday (score: 1)
Author: Ben Greear <greearb@xxxxxxxxxxxxxxx>
Date: Fri, 03 Oct 2003 09:42:19 -0700
Mitchell Blank Jr wrote: David S. Miller wrote: 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 pr
/archives/netdev/2003-10/msg00090.html (10,660 bytes)

13. do_gettimeofday (score: 1)
Author: Steve Modica <modica@xxxxxxx>
Date: Thu, 02 Oct 2003 13:32:27 -0500
We've been doing some experiments here with large numbers of adapters on a 64p Linux system. When running 8 threads and 8 cpus, the do_gettimeofday code starts to use a lot of time. It turns out that
/archives/netdev/2003-10/msg00774.html (9,264 bytes)

14. Re: do_gettimeofday (score: 1)
Author: Andi Kleen <ak@xxxxxxx>
Date: Thu, 2 Oct 2003 21:29:42 +0200
That's a known problem. The funny thing is that the only users of this time stamp is SO_TIMESTAMP, which is rarely used (except tcpdump) and something in DECnet. IMHO the right fix is to add a global
/archives/netdev/2003-10/msg00778.html (8,629 bytes)

15. Re: do_gettimeofday (score: 1)
Author: Stephen Hemminger <shemminger@xxxxxxxx>
Date: Thu, 2 Oct 2003 12:56:25 -0700
Two problems: a. xtime is limited to HZ resolution which is insufficient for more advanced packet schedulers and rtt estimation. b. unlocked access to xtime is unsafe because it is not atomic! ATM is
/archives/netdev/2003-10/msg00779.html (10,715 bytes)

16. Re: do_gettimeofday (score: 1)
Author: Mitchell Blank Jr <mitch@xxxxxxxxxx>
Date: Thu, 2 Oct 2003 13:46:36 -0700
It got fixed in 2.5 (when skb->stamp got changed to nanosecond resolution so it broke the compile to do it the old way) You can use LXR to see all of the xtime users as of 2.6.0-test2: http://lxr.lin
/archives/netdev/2003-10/msg00780.html (9,305 bytes)

17. Re: do_gettimeofday (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxx>
Date: Fri, 3 Oct 2003 00:41:33 -0700
Yes, this issue is well known and it gets brought up again from time to time. And it's by no means just SO_TIMESTAMP that uses the skb->stamp values, even IPV4/IPV6 fragmentation uses these things. T
/archives/netdev/2003-10/msg00809.html (11,312 bytes)

18. Re: do_gettimeofday (score: 1)
Author: Mitchell Blank Jr <mitch@xxxxxxxxxx>
Date: Fri, 3 Oct 2003 01:26:42 -0700
Are there any common cases where skb->stamp is looked at more than once? If so I might recommend changing the API to be more like: const struct timeval *skb_timestamp(struct skbuff *skb); where the g
/archives/netdev/2003-10/msg00810.html (10,945 bytes)

19. Re: do_gettimeofday (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxx>
Date: Fri, 3 Oct 2003 01:27:54 -0700
Yes, the packet scheduler can cause this to happen. Please no, making this a SKB or networking specific interface make it nearly valueless and we might as well just stay with the stuff we have. Doesn
/archives/netdev/2003-10/msg00811.html (9,612 bytes)

20. Re: do_gettimeofday (score: 1)
Author: Mitchell Blank Jr <mitch@xxxxxxxxxx>
Date: Fri, 3 Oct 2003 01:48:47 -0700
That's definately the worst case. You could have each CPU periodically store its current {tsc,timeval} tuple in a per-cpu location and extrapolate from that. It all depends on what percentage of skb'
/archives/netdev/2003-10/msg00812.html (9,507 bytes)


This search system is powered by Namazu