Messages in this thread | | | Date | Mon, 11 Dec 2006 22:32:36 +0100 | From | Andrea Arcangeli <> | Subject | Re: rdtscp vgettimeofday |
| |
On Mon, Dec 11, 2006 at 01:17:25PM -0800, dean gaudet wrote: > rdtscp doesn't solve anything extra [..] > [..] lsl-based vgetcpu is relatively slow
Well, if you accept to run slow there's nothing to solve in the first place indeed.
If nothing else rdtscp should avoid the mess of restarting a vsyscalls, which is quite a difficult problem as it heavily depends on the compiler/dwarf.
> even with rdtscp you have to deal with the definite possibility of being > scheduled away in the middle of the computation. arguably you need > to
Isn't rdtscp atomic? all you need is to read atomically the current contents of the tsc and the index to use in a per-cpu table exported in readonly. This table will contain a per-cpu seqlock as well. Then a math logic has to be built with per-cpu threads, so that those per-cpu tables are updated by cpufreq and at regular intervals.
If this is all wrong and it's not feasible to implement a safe and monothonic vgettimeofday that doesn't access the southbridge and that doesn't require restarting the vsyscall manually by patching rip/rsp, I've an hard time to see how rdtscp is useful at all. I hope somebody thought about those issues before adding a new instruction to a popular CPU ;). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |