Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp77915imm; Tue, 22 May 2018 14:18:51 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpJSOqK6N6rdFobqoKEON9tbUPKC8ULLw+4DgRcdfQA9lXxJYBMKv+gKvylPzVcdQevc285 X-Received: by 2002:a62:4d02:: with SMTP id a2-v6mr138124pfb.2.1527023931165; Tue, 22 May 2018 14:18:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527023931; cv=none; d=google.com; s=arc-20160816; b=kiNS/ZKfbvrEOTZtVMe/kdYlhpja1sGR5/4RKtQPZ6wmKKVhc8zv6WAC+ILzhzg58J xJpdRCQ6BABLvF1wlQpYlpAoIwTA+t2GfFEpycDqm4RO0xgXNR9onvusG7xMT40h1A/I 3idmfC8xP7QSbnY1KYEfetAqvrbOLbttFoXZspidp1hANFk5kcbYlrIkhr95y44L0i3S 5uYfp1YTT8UEmGSj+cPJaDOxPTn0ik9CxlgLe/kYfmhr6W9M3XbtZUYaS/bNoORt6nTQ jTVv5demcYe72HPRUVCaVY0rhqN+PFlw8NrrammCF9dg3yzsNDMlFhEjyBvk+qoYRQkA 5Uug== 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:dkim-signature:arc-authentication-results; bh=UMVpYn27yCInqlMDW4iW4IHbNoyATWT4MLWdTLuSB/g=; b=iqSXpfIMxirWigJERD4fO/NivOMxO24GeC0ZRFkh52K9sauJU5i/I640Z8n7wCeb7h ba4DAJibadKPG2qnaPel8fjpkU1k/0E/hVOZ1FuKykGXeQ3p8yLcQ672zPYOzB2ZCgrU FywkK05EHyuvjD8SSm5uPSnrRtudEHk//aGJsWEQL2MsxGuEdPKHUDe0LeIG9tV3fYm5 y9DfCaWRNSAP9uPoFetUD1fV9iWuph8sSRFZvS+aej6RFHXlKeTN2STl0mwJKboa7pbl HoTAmOVACZ/JnE7qSqcx5deI17P5eiUMY6TaJI3hUiv06T+vRHBmtyvyKIKfKmiRPPp2 IIeg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=p1Utpjev; 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 u8-v6si2852234pgp.685.2018.05.22.14.18.36; Tue, 22 May 2018 14:18:51 -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; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=p1Utpjev; 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 S1753049AbeEVVRv (ORCPT + 99 others); Tue, 22 May 2018 17:17:51 -0400 Received: from merlin.infradead.org ([205.233.59.134]:54940 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752660AbeEVVRt (ORCPT ); Tue, 22 May 2018 17:17:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=UMVpYn27yCInqlMDW4iW4IHbNoyATWT4MLWdTLuSB/g=; b=p1UtpjevGJqs4nQHEpDAC3WVV DlWNSmBAbkXD4HB/wSUqc8LTcKYkFc5Bx+jbLI6oH/qcBJWiutFB+945nXyX56l9dCAHgJUmKcjGK Di7/g6+Fd6Dd4BZ+QefMAOTo20JnEqGtKmwiydRH9dw/kK4TNlhipMoZJUlgBI8nR3PBJWzMTD20C xb/V2el9xNGF6NHeeuFGVi9EyqkoApOV+2hfJprRhj1NzbsvM95PkXVoDqHUOCP0byFfgrKlm8WwB 2YIB4ge7Wj9tkStnO93aw4pxCUNw2XOlnMuvhGATj+mA6+VX09a6AIXS9uvR04NxpMFA5hk7rPECP yHt99MhHQ==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=hirez.programming.kicks-ass.net) by merlin.infradead.org with esmtpsa (Exim 4.90_1 #2 (Red Hat Linux)) id 1fLEeu-0005dn-Ci; Tue, 22 May 2018 21:17:28 +0000 Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 2E7EB2029F869; Tue, 22 May 2018 23:17:24 +0200 (CEST) Date: Tue, 22 May 2018 23:17:24 +0200 From: Peter Zijlstra To: Linus Torvalds Cc: psodagud@codeaurora.org, Kees Cook , Andy Lutomirski , Will Drewry , Andrew Morton , Rik van Riel , Thomas Gleixner , Ingo Molnar , Eric Biggers , Frederic Weisbecker , sherryy@android.com, Vegard Nossum , Christoph Lameter , Andrea Arcangeli , Sasha Levin , Linux Kernel Mailing List Subject: Re: write_lock_irq(&tasklist_lock) Message-ID: <20180522211724.GR12217@hirez.programming.kicks-ass.net> References: <0879f797135033e05e8e9166a3c85628@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.5 (2018-04-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 22, 2018 at 01:27:17PM -0700, Linus Torvalds wrote: > It's usually not a huge problem because there are so few writers, but what > you're seeing is the writer starvation issue because readers can be > plentiful. qrwlock is a fair lock and should not exhibit writer starvation. Write acquire time is of course proportional to the number of CPUs in the system because each can be holding a reader, but once there is a pending writer there should not be new readers. > > Do we need write_lock_irq(&tasklist_lock) in below portion of code ? Can > > I use write_unlock instead of write_lock_irq in portion of code? > > You absolutely need write_lock_irq(), because taking the tasklist_lock > without disabling interrupts will deadlock very quickly due to an interrupt > taking the tasklist_lock for reading. > > That said, the write_lock_irq(&tasklist_lock) could possibly be replaced > with something like > > static void tasklist_write_lock(void) > { > unsigned long flags; > local_irq_save(flags); > while (!write_trylock(&tasklist_lock)) { > local_irq_restore(flags); > do { cpu_relax(); } while (write_islocked(&tasklist_lock)); > local_irq_disable(); > } > } > > but we don't have that "write_islocked()" function. You basically want to spin-wait with interrupts enabled, right? I think there were problems with that, but I can't remember, my brain is entirely shot for the day. But given how qrwlock is constructed, you'd have to look at the arch spinlock implementation for that (qspinlock for x86). The obvious problem of course is: spin_lock_irq(&L) // contended local_irq_enable(); while(...) cpu_relax(); spin_lock(&L); Which because the spinlock is fair, is an instant deadlock. You can do the IRQ enabled spin-wait for unfair locks, but by now all our locks are fair (because we kept hitting starvation).