From mboxrd@z Thu Jan 1 00:00:00 1970 From: "H. Peter Anvin" Date: Mon, 29 Mar 2010 18:56:26 +0000 Subject: Re: [lm-sensors] [PATCH 1/3] resource: shared I/O region support Message-Id: <4BB0F7DA.6080603@zytor.com> List-Id: References: <20100325125005.6d58cfaf@lxorguk.ukuu.org.uk> <1269523063-30346-1-git-send-email-me@mortis.eu> <20100325155705.1ec79dbc@lxorguk.ukuu.org.uk> <20100325180347.GA2761@salidar.me.mortis.eu> <20100325181633.0313b8a5@lxorguk.ukuu.org.uk> <20100329081834.GB27956@salidar.me.mortis.eu> <20100329090713.1317942b@jbarnes-piketon> <20100329173800.GA3583@salidar.me.mortis.eu> <4BB0E73F.2080104@zytor.com> <20100329193933.1a04762b@lxorguk.ukuu.org.uk> In-Reply-To: <20100329193933.1a04762b@lxorguk.ukuu.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Alan Cox Cc: Giel van Schijndel , Jesse Barnes , Hans de Goede , Jean Delvare , Jonathan Cameron , Andrew Morton , Bjorn Helgaas , Dominik Brodowski , Laurens Leemans , lm-sensors@lm-sensors.org, linux-kernel@vger.kernel.org On 03/29/2010 11:39 AM, Alan Cox wrote: >> What I *really* object to with this patch is that it inherently assumes >> that there is only one multiplexed resource in the entire system... but >> of course nowhere enforces that. > > The patch does nothing of the sort. Not unless there is a bug I am not > seeing anyway. It does assume nobody tries to grab pairs of such > resources as it doesn't do deadlock avoidance. > > It's now a shared resource patch however, its a multiplexor patch and > that is precisely why it is called MUX not SHARED or OVERLAY > Alan Sorry, I missed the "continue", which of course handles the situation I was worried about. The shared wait queue is a bit inelegant, but if it turns out to be a bottleneck in real life then we either have bigger problems or it can be addressed at that time. -hpa _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752642Ab0C2TBm (ORCPT ); Mon, 29 Mar 2010 15:01:42 -0400 Received: from terminus.zytor.com ([198.137.202.10]:53460 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750957Ab0C2TBl (ORCPT ); Mon, 29 Mar 2010 15:01:41 -0400 Message-ID: <4BB0F7DA.6080603@zytor.com> Date: Mon, 29 Mar 2010 11:56:26 -0700 From: "H. Peter Anvin" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.7) Gecko/20100120 Fedora/3.0.1-1.fc12 Thunderbird/3.0.1 MIME-Version: 1.0 To: Alan Cox CC: Giel van Schijndel , Jesse Barnes , Hans de Goede , Jean Delvare , Jonathan Cameron , Andrew Morton , Bjorn Helgaas , Dominik Brodowski , Laurens Leemans , lm-sensors@lm-sensors.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/3] resource: shared I/O region support References: <20100325125005.6d58cfaf@lxorguk.ukuu.org.uk> <1269523063-30346-1-git-send-email-me@mortis.eu> <20100325155705.1ec79dbc@lxorguk.ukuu.org.uk> <20100325180347.GA2761@salidar.me.mortis.eu> <20100325181633.0313b8a5@lxorguk.ukuu.org.uk> <20100329081834.GB27956@salidar.me.mortis.eu> <20100329090713.1317942b@jbarnes-piketon> <20100329173800.GA3583@salidar.me.mortis.eu> <4BB0E73F.2080104@zytor.com> <20100329193933.1a04762b@lxorguk.ukuu.org.uk> In-Reply-To: <20100329193933.1a04762b@lxorguk.ukuu.org.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/29/2010 11:39 AM, Alan Cox wrote: >> What I *really* object to with this patch is that it inherently assumes >> that there is only one multiplexed resource in the entire system... but >> of course nowhere enforces that. > > The patch does nothing of the sort. Not unless there is a bug I am not > seeing anyway. It does assume nobody tries to grab pairs of such > resources as it doesn't do deadlock avoidance. > > It's now a shared resource patch however, its a multiplexor patch and > that is precisely why it is called MUX not SHARED or OVERLAY > Alan Sorry, I missed the "continue", which of course handles the situation I was worried about. The shared wait queue is a bit inelegant, but if it turns out to be a bottleneck in real life then we either have bigger problems or it can be addressed at that time. -hpa