| To: | "David S. Miller" <davem@xxxxxxxxxx> |
|---|---|
| Subject: | Re: do_gettimeofday |
| From: | Mitchell Blank Jr <mitch@xxxxxxxxxx> |
| Date: | Fri, 3 Oct 2003 01:48:47 -0700 |
| Cc: | netdev@xxxxxxxxxxx |
| In-reply-to: | <20031003012754.23de3f66.davem@xxxxxxxxxx> |
| References: | <3F7C6F3B.6070502@xxxxxxx> <20031002125625.72b8c0a7.shemminger@xxxxxxxx> <20031003004133.3148c39a.davem@xxxxxxxxxx> <20031003082642.GF42593@xxxxxxxxxxxxxx> <20031003012754.23de3f66.davem@xxxxxxxxxx> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
| User-agent: | Mutt/1.4.1i |
David S. Miller wrote:
> Doesn't work as-is. You'd have to not only store the timestamp and
> the cpu it was stored on, but also cross-call to that cpu to compute
> the correct timeval.
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.
> That's really expensive and probably
> do_gettimeofday() is going to be faster in the long run compared to
> such a scheme.
It all depends on what percentage of skb's have ->stamp computed on a
CPU different from the one they came it on. For the common users of
->stamp won't they have stayed on the same CPU? The worst case of
doing a cross-cpu-call should only happen relatively rarely.
-Mitch
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: do_gettimeofday, David S. Miller |
|---|---|
| Next by Date: | Re: do_gettimeofday, David S. Miller |
| Previous by Thread: | Re: do_gettimeofday, David S. Miller |
| Next by Thread: | Re: do_gettimeofday, David S. Miller |
| Indexes: | [Date] [Thread] [Top] [All Lists] |