From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2992972AbbEPJDp (ORCPT ); Sat, 16 May 2015 05:03:45 -0400 Received: from mail-ie0-f173.google.com ([209.85.223.173]:32826 "EHLO mail-ie0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933675AbbEPJDl (ORCPT ); Sat, 16 May 2015 05:03:41 -0400 MIME-Version: 1.0 X-Originating-IP: [85.250.79.171] In-Reply-To: <20150511144608.GB16124@linaro.org> References: <1430500026-47990-1-git-send-email-lina.iyer@linaro.org> <20150511144608.GB16124@linaro.org> From: Ohad Ben-Cohen Date: Sat, 16 May 2015 12:03:19 +0300 Message-ID: Subject: Re: [PATCH RFC] hwspinlock: Don't take software spinlock before hwspinlock To: Lina Iyer Cc: "Anna, Suman" , Bjorn Andersson , Andy Gross , "linux-arm-msm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Kumar Gala , Jeffrey Hugo Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 11, 2015 at 5:46 PM, Lina Iyer wrote: > On Sat, May 09 2015 at 03:25 -0600, Ohad Ben-Cohen wrote: >> On Fri, May 1, 2015 at 8:07 PM, Lina Iyer wrote: >> Let's discuss whether we really want to expose this functionality >> under the same hwspinlock API or not. >> >> In this new mode, unlike previously, users will now be able to sleep >> after taking the lock, and others trying to take the lock might poll >> the hardware for a long period of time without the ability to sleep >> while waiting for the lock. It almost sounds like you were looking for >> some hwmutex functionality. > > I agree, that it opens up a possiblity that user may sleep after holding > a hw spinlock. But really, why should it prevents us from using it as a > hw mutex, if the need is legitimate? If we want hw mutex functionality, let's discuss how to expose it. Exposing it using the existing hw spinlock API might not be ideal, as users might get confused. Additionally, there are hardware IP locking blocks out there which encourage users to sleep while waiting for a lock, by providing interrupt functionality to wake them up when the lock is freed. So if we choose to add a hw mutex API it might be used by others in the future too (though this reason alone is not why we would choose to add it now of course). API discussions aside, what do you want to happen in your scenario while the lock is taken? are you OK with other users spinning on the lock waiting for it to be released? IIUC that might mean processors spinning for a non-negligible period of time? Thanks, Ohad.