From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752744AbcC3GHJ (ORCPT ); Wed, 30 Mar 2016 02:07:09 -0400 Received: from mx2.suse.de ([195.135.220.15]:60081 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751027AbcC3GHH (ORCPT ); Wed, 30 Mar 2016 02:07:07 -0400 Date: Wed, 30 Mar 2016 08:07:04 +0200 Message-ID: From: Takashi Iwai To: Andy Lutomirski Cc: Luis Rodriguez , Konstantin Ozerkov , "linux-kernel@vger.kernel.org" , ALSA development Subject: Re: Getting rid of inside_vm in intel8x0 In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/24.5 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 29 Mar 2016 23:37:32 +0200, Andy Lutomirski wrote: > > Would it be possible to revert: > > commit 228cf79376f13b98f2e1ac10586311312757675c > Author: Konstantin Ozerkov > Date: Wed Oct 26 19:11:01 2011 +0400 > > ALSA: intel8x0: Improve performance in virtual environment > > Presumably one or more of the following is true: > > a) The inside_vm == true case is just an optimization and should apply > unconditionally. > > b) The inside_vm == true case is incorrect and should be fixed or disabled. > > c) The inside_vm == true case is a special case that makes sense then > IO is very very slow but doesn't make sense when IO is fast. If so, > why not literally measure the time that the IO takes and switch over > to the "inside VM" path when IO is slow? More important condition is rather that the register updates of CIV and PICB are atomic. This is satisfied mostly only on VM, and can't be measured easily unlike the IO read speed. > There are a pile of nonsensical "are we in a VM" checks of various > sorts scattered throughout the kernel, they're all a mess to maintain > (there are lots of kinds of VMs in the world, and Linux may not even > know it's a guest), and, in most cases, it appears that the correct > solution is to delete the checks. I just removed a nasty one in the > x86_32 entry asm, and this one is written in C so it should be a piece > of cake :) This cake looks sweet, but a worm is hidden behind the cream. The loop in the code itself is already a kludge for the buggy hardware where the inconsistent read happens not so often (only at the boundary and in a racy way). It would be nice if we can have a more reliably way to know the hardware buggyness, but it's difficult, unsurprisingly. thanks, Takashi