Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp2011909imm; Thu, 9 Aug 2018 06:01:18 -0700 (PDT) X-Google-Smtp-Source: AA+uWPzwstSes/TP/ChtYkj2iBwUHPHpYuILiQp1MKOOsh4T37e+U2nXPxLo1lbdat/TDlW38kQ0 X-Received: by 2002:a63:ae42:: with SMTP id e2-v6mr2070931pgp.351.1533819678715; Thu, 09 Aug 2018 06:01:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533819678; cv=none; d=google.com; s=arc-20160816; b=JJVZaW9PFm9yLOqjkO4RCzVlSAn79UT0NC7oaVPL3nP9ln1L95pSIXyQOWeoTyvYsg Tm3lHw2P8+srLeXPC2awVxu87+j9cfb6qC0ihelf5PzWkqfLIisN1rYpUhLA1h8LcHln q4aZJFLd98EfQmKb5bxpscqRsGlj9zQ49lrBHqyKzfrJrAGIj+xhnqI3v0FT2KFvWoQm 2EPTPQRXSCWZthuAU3wcgcWxY3snsFx0yV4It5eG7ZQClNJsiAo4gk5Z695cOYHc7ShL unqB9/TldaTt8RQhToYbW9yQ0ueQcCy7CkJMh7jkXYNC/HKossif6iDlw6QDYDsj2kAO e4iQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=zAJ1NtDUhz7tzVrscHxmOdMargyJpqC1Iy7jKiUs02Y=; b=vNVigFPBstDG77qRgrYy0Sl2cOd+gOvH8fHhcQDTWQX6h75IGjAnO78vICzDHC/Qja WA7U5n0dGOSa2lxWDGFDtKqpYaZuO5Qrzeyc4be2ckPh6Z14wz9yUs8MtCkcIdO98ylq ajzafdNOG+7yJIqyENpkoVIj+d4DtNrfaLBzA9Hx92uD3RpTk3x7BGYToXAKqpllqggi 6IoxZDZ9z2tU1F4113z+6b0jFx2fkn6zWmJg7ayvpQvP7JN1ibhi4SFl+nsVkSjnDOmy ghHlK7H/6xsnD2LNeTCo5/cxEjh9HPdQeNcFEb7vdEzyqaqNm4nUwIlheubmvHm/s7i2 swJQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p10-v6si5439089plo.434.2018.08.09.06.01.03; Thu, 09 Aug 2018 06:01:18 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731989AbeHIPYw (ORCPT + 99 others); Thu, 9 Aug 2018 11:24:52 -0400 Received: from fieldses.org ([173.255.197.46]:48322 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727786AbeHIPYv (ORCPT ); Thu, 9 Aug 2018 11:24:51 -0400 Received: by fieldses.org (Postfix, from userid 2815) id 4B4331E3D; Thu, 9 Aug 2018 09:00:01 -0400 (EDT) Date: Thu, 9 Aug 2018 09:00:01 -0400 From: "J. Bruce Fields" To: Jeff Layton Cc: NeilBrown , Alexander Viro , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Martin Wilck Subject: Re: [PATCH 0/4] locks: avoid thundering-herd wake-ups Message-ID: <20180809130001.GG23873@fieldses.org> References: <153369219467.12605.13472423449508444601.stgit@noble> <20180808195445.GD23873@fieldses.org> <20180808200912.GE23873@fieldses.org> <20180808212832.GF23873@fieldses.org> <04ffa27c29d2bff8bd9cb9b6d4ea6b6fd3969b6c.camel@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <04ffa27c29d2bff8bd9cb9b6d4ea6b6fd3969b6c.camel@kernel.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 08, 2018 at 06:50:06PM -0400, Jeff Layton wrote: > That seems like a legit problem. > > One possible fix might be to have the waiter on (1,2) walk down the > entire subtree and wake up any waiter that is waiting on a lock that > doesn't conflict with the lock on which it's waiting. > > So, before the task waiting on 1,2 goes back to sleep to wait on 2,2, it > could walk down its entire fl_blocked subtree and wake up anything > waiting on a lock that doesn't conflict with (2,2). > > That's potentially an expensive operation, but: > > a) the task is going back to sleep anyway, so letting it do a little > extra work before that should be no big deal I don't understand why cpu used by a process going to sleep is cheaper than cpu used in any other situation. > b) it's probably still cheaper than waking up the whole herd Yeah, I'd like to understand this. I feel like Neil's addressing two different performance costs: - the cost of waking up all the waiters - the cost of walking the list of waiters Are they equally important? If we only cared about the former, and only in simple cases, we could walk the entire list and skip waking up only the locks that conflict with the first one we wake. We wouldn't need the tree. --b.