Re: [PATCH] x86: Remove hpet vclock support

2014-02-04 Thread Thomas Gleixner
On Tue, 4 Feb 2014, Andy Lutomirski wrote: > On Tue, Feb 4, 2014 at 11:31 AM, Thomas Gleixner wrote: > > On Fri, 31 Jan 2014, Andy Lutomirski wrote: > > > >> The HPET is so amazingly slow that this is barely a win. It adds > > > > That's nonsense. It's definitely a win to access HPET directly > >

Re: [PATCH] x86: Remove hpet vclock support

2014-02-04 Thread Andy Lutomirski
On Tue, Feb 4, 2014 at 11:31 AM, Thomas Gleixner wrote: > On Fri, 31 Jan 2014, Andy Lutomirski wrote: > >> The HPET is so amazingly slow that this is barely a win. It adds > > That's nonsense. It's definitely a win to access HPET directly > especially on older systems with TSC wreckage. Why do yo

Re: [PATCH] x86: Remove hpet vclock support

2014-02-04 Thread Thomas Gleixner
On Fri, 31 Jan 2014, Andy Lutomirski wrote: > The HPET is so amazingly slow that this is barely a win. It adds That's nonsense. It's definitely a win to access HPET directly especially on older systems with TSC wreckage. Why do you want to enforce a syscall if we can read out the data straight f

Re: [PATCH] x86: Remove hpet vclock support

2014-02-01 Thread Andy Lutomirski
On Sat, Feb 1, 2014 at 7:43 AM, Clemens Ladisch wrote: > Andy Lutomirski wrote: >> The HPET is so amazingly slow that this is barely a win. > > What happens on CPUs where the TSC cannot be used for the clock? vclock_gettime, etc will fall back to using syscalls, just like they would on systems us

Re: [PATCH] x86: Remove hpet vclock support

2014-02-01 Thread Clemens Ladisch
Andy Lutomirski wrote: > The HPET is so amazingly slow that this is barely a win. What happens on CPUs where the TSC cannot be used for the clock? > it scares me a tiny bit to map a piece of crappy hardware where every > userspace program can poke at it (even if said poking is read-only). > Let's

[PATCH] x86: Remove hpet vclock support

2014-01-31 Thread Andy Lutomirski
The HPET is so amazingly slow that this is barely a win. It adds complexity, and it scares me a tiny bit to map a piece of crappy hardware where every userspace program can poke at it (even if said poking is read-only). Let's just remove it. This is probably a tiny speedup on kvmclock systems.