* Thomas Gleixner <t...@linutronix.de> wrote:
> On Fri, 4 Mar 2016, Andy Lutomirski wrote:
> > Thomas, I still think we should consider just deleting the HPET vclock
> > code and accept the syscall overhead on systems that are stuck using
> > HPET. If fast syscalls are available (which should include every
> > system with HPET, unless there are some 32-bit AMD systems lying
> > around), then the overhead in a syscall is *tiny* compared to the code
> > of the HPET read itself.
>
> No objection from my side, really.
Seconded. HPET hardware overhead is typically horrifically large in any case,
no
need to memory map it and expose hardware breakages to user-space ...
It's also a (mild) security hole: a well-known HPET address can be abused as a
statistical trampoline periodically cycling through 'dangerous' instruction
values.
Thanks,
Ingo
