Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp2062038ybb; Thu, 2 Apr 2020 12:19:28 -0700 (PDT) X-Google-Smtp-Source: APiQypJiS3oFf5V0wZry+owzWsYp4gJs80/sB3bnRE/sx8jwT/8VPhy+ylmvVpOIthBNNVcR5LXf X-Received: by 2002:a05:6830:22d9:: with SMTP id q25mr3532743otc.164.1585855167807; Thu, 02 Apr 2020 12:19:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585855167; cv=none; d=google.com; s=arc-20160816; b=Oz1VGcHw/EseKbXZEn64XP2kmirR2Uqrg8WVyJSvFTcotSflSlMmjvX6EiSm7s8VcF JhZAzuGtR8kFmtdLZOigW+wFp+bSJavrFlHF6vUb+fKMLDuk32lHptkzcZRY6p6o1bOJ qWa3ApIKK2gFW/mlYWctBb0hawhY+d3TYMNTBLAMQgkY30py+ZaVQ1lBlJ0DykcIincv QGDuhLBxgUZNy9gR/23QIcwOVlzEuRB1WjRadU3DYY562iQWJrQh6+YHstGGX7Sg4jps Zmq9wQiaXU46MS1y53XrhebGqJbGfU/3WdvoVXyzBYZ6MleYshvFMOEmJs4AV9Y3gQX7 AY5A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=RlBOg0dum66ebZmfIZrWlU1IBkKC8efn4oYc6hOU1L0=; b=B83CmdZrYARs9n0PvmC5xqaXCOWMZrxDGmJNtLowZtVUeBOwciCoD9vj9sJHhzCQb+ l8SU3XIzTGvA+ATZFwT2xbB2Orvrl0psM83GjuiyU7kt9QQT/jb5ewq8aAx7qxZbpDEh 8ka3phbiDacBHCS6kiecxa+C3fStfiMk4ZCOsWB25dsmpLEWUNXZECT6uSbeML36V7Xq FU+KaTUAR8AdEXAWVrsnfydNC8ai9BmPp3uCHVxRPNknVkOtxGys/JXtVqQ2jrnzC98C YG6cdxG5iHjptVr3sOZIneTaWQrcUS+DsWIHOrNUorKCpUj4uLyDAjN3hAxwrXjfSfhk vFMw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=hvEITigZ; 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 j69si2725095oib.93.2020.04.02.12.19.14; Thu, 02 Apr 2020 12:19:27 -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=pass header.i=@linux-foundation.org header.s=google header.b=hvEITigZ; 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 S1732600AbgDBSGr (ORCPT + 99 others); Thu, 2 Apr 2020 14:06:47 -0400 Received: from mail-lj1-f196.google.com ([209.85.208.196]:38489 "EHLO mail-lj1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728225AbgDBSGr (ORCPT ); Thu, 2 Apr 2020 14:06:47 -0400 Received: by mail-lj1-f196.google.com with SMTP id v16so4254988ljg.5 for ; Thu, 02 Apr 2020 11:06:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RlBOg0dum66ebZmfIZrWlU1IBkKC8efn4oYc6hOU1L0=; b=hvEITigZV32UOF8ubiUjd+p22kCZAiMJFfBqDEEHBqM8+KyLyY3+cjtQPsswx+RUpm HJ1KgeDiJRSfzbkwXPk1cZ6pfQGvYJULSwuj6II4fCP3quqyDwcIFxIxB2CVRWFVsr87 Cmk6cMB40cebsPRptNEHYRfJuiAA45R2UT23k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RlBOg0dum66ebZmfIZrWlU1IBkKC8efn4oYc6hOU1L0=; b=Bg43PsJRSzAZCyexC793mcLueFY6WCiUhK35dOunM3J65IXE3s6dEURCO4zAfZo/eH vzSGVCp1qDEYTXjVmrIwoZmEPTeviz/hl4Tq9s1vkSxr7Z/krnf4gRnPVYK2vMxvBzsc AYHRhpqmRm1Cc9MG+Bka2FrA0jCoTRmj/xJapaCnmUZDY7+bN6rCjW56uXgtfnPKdst2 sWf8og2bB3uNg9gC3SrIbt1T0pAsHI2q7t7KP8IPRJPGaTgRFxKYXy58endLvHnwpbWI BEyFhwM5E9IoBrhdpkgDz/LN3yY9fPl6u0U8iBgyYQ2Rk6gJi19U/WwyUZifKdDJNYp7 WnYw== X-Gm-Message-State: AGi0PuYeIwqVV811PUgGdUfK75uMDVkI8PBWnwqqFeCuzfVf8eXkj11Z FlaOi0gmVS2EVLUaDmlHywWUxhAtr40= X-Received: by 2002:a2e:b4cb:: with SMTP id r11mr2785176ljm.201.1585850803940; Thu, 02 Apr 2020 11:06:43 -0700 (PDT) Received: from mail-lj1-f181.google.com (mail-lj1-f181.google.com. [209.85.208.181]) by smtp.gmail.com with ESMTPSA id b4sm2063742lfo.36.2020.04.02.11.06.42 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 02 Apr 2020 11:06:43 -0700 (PDT) Received: by mail-lj1-f181.google.com with SMTP id g27so4195928ljn.10 for ; Thu, 02 Apr 2020 11:06:42 -0700 (PDT) X-Received: by 2002:a2e:8652:: with SMTP id i18mr2793744ljj.265.1585850802219; Thu, 02 Apr 2020 11:06:42 -0700 (PDT) MIME-Version: 1.0 References: <20200324215049.GA3710@pi3.com.pl> <202003291528.730A329@keescook> <87zhbvlyq7.fsf_-_@x220.int.ebiederm.org> <877dyym3r0.fsf@x220.int.ebiederm.org> In-Reply-To: <877dyym3r0.fsf@x220.int.ebiederm.org> From: Linus Torvalds Date: Thu, 2 Apr 2020 11:06:02 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] signal: Extend exec_id to 64bits To: "Eric W. Biederman" Cc: Jann Horn , Alan Stern , Andrea Parri , Will Deacon , Peter Zijlstra , Boqun Feng , Nicholas Piggin , David Howells , Jade Alglave , Luc Maranget , "Paul E. McKenney" , Akira Yokosawa , Daniel Lustig , Adam Zabrocki , kernel list , Kernel Hardening , Oleg Nesterov , Andy Lutomirski , Bernd Edlinger , Kees Cook , Andrew Morton , stable , Marco Elver , Dmitry Vyukov , kasan-dev Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 2, 2020 at 6:14 AM Eric W. Biederman wrote: > > Linus Torvalds writes: > > > tasklist_lock is aboue the hottest lock there is in all of the kernel. > > Do you know code paths you see tasklist_lock being hot? It's generally not bad enough to show up on single-socket machines. But the problem with tasklist_lock is that it's one of our remaining completely global locks. So it scales like sh*t in some circumstances. On single-socket machines, most of the truly nasty hot paths aren't a huge problem, because they tend to be mostly readers. So you get the cacheline bounce, but you don't (usually) get much busy looping. The cacheline bounce is "almost free" on a single socket. But because it's one of those completely global locks, on big multi-socket machines people have reported it as a problem forever. Even just readers can cause problems (because of the cacheline bouncing even when you just do the reader increment), but you also end up having more issues with writers scaling badly. Don't get me wrong - you can get bad scaling on other locks too, even when they aren't really global - we had that with just the reference counter increment for the user signal accounting, after all. Neither of the reference counts were actually global, but they were just effectively single counters under that particular load (ie the count was per-user, but the load ran as a single user). The reason tasklist_lock probably doesn't come up very much is that it's _always_ been expensive. It has also caused some fundamental issues (I think it's the main reason we have that rule that reader-writer locks are unfair to readers, because we have readers from interrupt context too, but can't afford to make normal readers disable interrupts). A lot of the tasklist lock readers end up looping quite a bit inside the lock (looping over threads etc), which is why it can then be a big deal when the rare reader shows up. We've improved a _lot_ of those loops. That has definitely helped for the common cases. But we've never been able to really fix the lock itself. Linus