> It just seems to me unwise to make an ABI commitment to something
> that's not guaranteed by the architecture, perverse though it might
> seem for the chip designers to take it away. CPU designers have been
> known to do some fairly perverse things from time to time..
What would you prefer? Letting them continue to use RDTSC
which is less and less an usable cycle count? Telling the users
it's a bad idea without offering a credible alternative
for cycle counting?
And if they break it the kernel can always trap it, so there's
at least a safety net.
One alternative would be to make a function in the vsyscall page, but
that would add at least an indirect function call which can be quite
slow and I can just hear people complaining about that.
Also there are only two slots in the vsyscall page left right now and I
already planned them for other things (although it would be possible to go
for a full vDSO, just a lot of overhead)
-Andi
-
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]
