From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751666AbcDIWtb (ORCPT ); Sat, 9 Apr 2016 18:49:31 -0400 Received: from www.linutronix.de ([62.245.132.108]:54966 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750783AbcDIWta (ORCPT ); Sat, 9 Apr 2016 18:49:30 -0400 Date: Sat, 9 Apr 2016 15:47:47 -0700 (PDT) From: Thomas Gleixner To: Andy Lutomirski cc: Borislav Petkov , x86@kernel.org, linux-kernel@vger.kernel.org, Waiman Long Subject: Re: [PATCH] x86/vdso: Remove direct HPET access through the vDSO In-Reply-To: Message-ID: References: User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 7 Apr 2016, Andy Lutomirski wrote: > Allowing user code to map the HPET is problematic. HPET > implementations are notoriously buggy, and there are probably many > machines on which even MMIO reads from bogus HPET addresses are > problematic. > > We have a report that the Dell Precision M2800 with: > > ACPI: HPET 0x00000000C8FE6238 000038 (v01 DELL CBX3 01072009 AMI. 00000005) > > is either so slow when accessing the HPET or actually hangs in some > regard, causing soft lockups to be reported if users do unexpected > things to the HPET. > > The vclock HPET code has also always been a questionable speedup. > Accessing an HPET is exceedingly slow (on the order of several > microseconds), so the added overhead in requiring a syscall to read > the HPET is a small fraction of the total code of accessing it. > > To avoid future problems, let's just delete the code entirely. > > In the long run, this could actually be a speedup. Waiman Long as a > patch to optimize the case where multiple CPUs contend for the HPET, > but that won't help unless all the accesses are mediated by the > kernel. > > Cc: Waiman Long > Reported-by: Rasmus Villemoes > Signed-off-by: Andy Lutomirski Reviewed-by: Thomas Gleixner