Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759217AbcLAOgx (ORCPT ); Thu, 1 Dec 2016 09:36:53 -0500 Received: from mail.fireflyinternet.com ([109.228.58.192]:64282 "EHLO fireflyinternet.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752856AbcLAOgv (ORCPT ); Thu, 1 Dec 2016 09:36:51 -0500 X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=78.156.65.138; Date: Thu, 1 Dec 2016 14:36:00 +0000 From: Chris Wilson To: Nicolai =?iso-8859-1?Q?H=E4hnle?= Cc: linux-kernel@vger.kernel.org, Nicolai =?iso-8859-1?Q?H=E4hnle?= , Peter Zijlstra , Ingo Molnar , Maarten Lankhorst , Daniel Vetter , dri-devel@lists.freedesktop.org Subject: Re: [PATCH v2 02/11] locking/ww_mutex: Re-check ww->ctx in the inner optimistic spin loop Message-ID: <20161201143600.GF29430@nuc-i3427.alporthouse.com> Mail-Followup-To: Chris Wilson , Nicolai =?iso-8859-1?Q?H=E4hnle?= , linux-kernel@vger.kernel.org, Nicolai =?iso-8859-1?Q?H=E4hnle?= , Peter Zijlstra , Ingo Molnar , Maarten Lankhorst , Daniel Vetter , dri-devel@lists.freedesktop.org References: <1480601214-26583-1-git-send-email-nhaehnle@gmail.com> <1480601214-26583-3-git-send-email-nhaehnle@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1480601214-26583-3-git-send-email-nhaehnle@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1992 Lines: 55 On Thu, Dec 01, 2016 at 03:06:45PM +0100, Nicolai H?hnle wrote: > From: Nicolai H?hnle > > In the following scenario, thread #1 should back off its attempt to lock > ww1 and unlock ww2 (assuming the acquire context stamps are ordered > accordingly). > > Thread #0 Thread #1 > --------- --------- > successfully lock ww2 > set ww1->base.owner > attempt to lock ww1 > confirm ww1->ctx == NULL > enter mutex_spin_on_owner > set ww1->ctx > > What was likely to happen previously is: > > attempt to lock ww2 > refuse to spin because > ww2->ctx != NULL > schedule() > detect thread #0 is off CPU > stop optimistic spin > return -EDEADLK > unlock ww2 > wakeup thread #0 > lock ww2 > > Now, we are more likely to see: > > detect ww1->ctx != NULL > stop optimistic spin > return -EDEADLK > unlock ww2 > successfully lock ww2 > > ... because thread #1 will stop its optimistic spin as soon as possible. > > The whole scenario is quite unlikely, since it requires thread #1 to get > between thread #0 setting the owner and setting the ctx. But since we're > idling here anyway, the additional check is basically free. > > Found by inspection. Similar question can be raised for can_spin_on_owner() as well. Is it worth for a contending ww_mutex to enter the osq queue if we expect a EDEADLK? It seems to boil down to how likely is the EDEADLK going to evaporate if we wait for the owner to finish and unlock. The patch looks reasonable, just a question of desirability. -Chris -- Chris Wilson, Intel Open Source Technology Centre