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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
