From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id B8D4FC0218F for ; Sun, 2 Feb 2025 13:55:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 42985280004; Sun, 2 Feb 2025 08:55:09 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3D9696B0096; Sun, 2 Feb 2025 08:55:09 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 27A25280004; Sun, 2 Feb 2025 08:55:09 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 065976B0095 for ; Sun, 2 Feb 2025 08:55:08 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 8799A4AADB for ; Sun, 2 Feb 2025 13:55:08 +0000 (UTC) X-FDA: 83075151096.17.CC14731 Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) by imf01.hostedemail.com (Postfix) with ESMTP id 8F4F240008 for ; Sun, 2 Feb 2025 13:55:06 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Ab1PIzi2; spf=pass (imf01.hostedemail.com: domain of david.laight.linux@gmail.com designates 209.85.128.47 as permitted sender) smtp.mailfrom=david.laight.linux@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738504506; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=lNsfBeiHTtzxl6IYb/LvgDExYuDS/f8NcFRrBwdh198=; b=dkMlAdpe2+zivZyjJ/3OzDmp+aBQGCY/nfU0BvBjT1vM4VWtTD8Z4xWndydnfKU1UWHYPs dHkbcs2v4YUWluwGmDDKFEKuyZvQaUTy4kl4xfYKzryuJHHWf6E4sC5Zkxl/qWcUcUNGLP +IMRQ4u2TqgLzcyXUc9zcj/6HESbBZA= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Ab1PIzi2; spf=pass (imf01.hostedemail.com: domain of david.laight.linux@gmail.com designates 209.85.128.47 as permitted sender) smtp.mailfrom=david.laight.linux@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738504506; a=rsa-sha256; cv=none; b=ApZvGfHfQc/oumvmEx7exWcs65FRwQEiqrE6iSezsi+hYFhfVeQwCMUPb3nvQTiV2CC2vO n5qwUkEQwfpXFSYx19arZffwG+fDmwibpEYrEfhzbrj61dOcqF6rSTRXQvQOe/WjAbhDam J7cYwom1DuTxX6loCuT58p7FLyDfs5w= Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-436ce2ab251so24043055e9.1 for ; Sun, 02 Feb 2025 05:55:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1738504505; x=1739109305; darn=kvack.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=lNsfBeiHTtzxl6IYb/LvgDExYuDS/f8NcFRrBwdh198=; b=Ab1PIzi2715jdTGwDdY8dEbIUJPKXtT5HAIFoyI+hHHF74I6y0M0aU56YK0cgw7D7S JzASTb69g2fLQW+S66orPE8vtHiO96ooUtNLU1IT57xASYrHD3xu5JR/LiWqNuRWLJMf ya1nDm/cCwh4XRaTkzNVtbrL10JzpsU6PKc1B/j29OaJKHdF5qnEUd0K+FLJJTgEAhw6 0/UYaiX5FIOmSrqZ6a/dT3+USIt1FNfn2TkbArm6xHXbEOfGoFLWzkguH+hEMXJitMti HDw3YyKkRjXhFvvorWKLxZncTWJMCxIDGFbmkzg2cr2cwfV3HxC7PXQdK0UA9UaDSFvM I+dA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738504505; x=1739109305; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=lNsfBeiHTtzxl6IYb/LvgDExYuDS/f8NcFRrBwdh198=; b=ui5JuPTfKeoioRiASP3wZOXByNc1DffVbK7tpXgonH1BjNKdxSuo2jGWbKiyIMNY3f DvrDAAHv6u2Ogt8xubeUndiExJ2q/sHAm1RG2NxmwOEZHGpeR1LQTMOEI77oe3THa1Dj s2WRf4uuiyBJrU73kRztxiYe2FuTlQ8FH+FHcE1bKjZUv1YtWKtYfj7mERoUX8tj6JnA ZlVUS7/MoCeLJb6IPbSvXCOAsMmQz2TgbZUWKMrrShoBFOCWeN575AKAOtkD0BVDXWSi x6VdshIik3P8TUD/8uT9USglQiUXuebF9/BQSE6vWs6fooi2vh/zEbuyHvdXoBIMLoDU bU9g== X-Forwarded-Encrypted: i=1; AJvYcCX0NqiJYwLIP93YFMXs/vBPfeot+ttp9s2Co+fGXSfOQHM4Kheu3+CLu5m5TKsO1dxEd4DTzsHGTw==@kvack.org X-Gm-Message-State: AOJu0YzospMFrQfTGieWz8EnOkbtWoQxfApp/x0zGTBqQKiRBGWOxJQn M0Hq0FYngqaXiS7EGvqE+KBqF/3SdP3Q+IoIaMmB1n83bC0ylP0A X-Gm-Gg: ASbGncueLaSZEsTwkbUb98k7J6m8QU0zFojrQbXGH/ARzpRm100XJBf4qjgsll4Z+Lj OKmMeAb0bzielTXv5P29xNGkzNGKmHctLrv8nqG4jbn4Iu906z78X0MrIZwjxCBZT1cj6VRjIz3 6cS4GmXbYuw2DO1E22xBos2Xi8O6Tp939TwthapZZcFrYKKeszHjvZ8ooHVjOkXKzTbjnXUD8W0 45OOD1VJmw/7z0TPiZkO2Zf+MINz9iKvda2KeIAvLRTpHLDu03wtNc1R1ZYtbGvRgVCgm7XQmGi Yz3OW2gvg7fOVpxyptjeNTSd8IqW+MWFUYgSboiGazeve5sQYWX0wg== X-Google-Smtp-Source: AGHT+IEBNI/DwNheuqMMc3AK7zFn0rGRjMIyiwjKBnh/JppCyA6dLcUGmxYDuLRS1uLCifEG6CJEsw== X-Received: by 2002:a05:600c:45c5:b0:434:e2ea:fc94 with SMTP id 5b1f17b1804b1-438dc3c3292mr192346765e9.11.1738504504732; Sun, 02 Feb 2025 05:55:04 -0800 (PST) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-438dcc6df36sm162294865e9.25.2025.02.02.05.55.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 02 Feb 2025 05:55:04 -0800 (PST) Date: Sun, 2 Feb 2025 13:55:03 +0000 From: David Laight To: Matthew Wilcox Cc: Mateusz Guzik , ebiederm@xmission.com, oleg@redhat.com, brauner@kernel.org, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [PATCH v3 6/6] pid: drop irq disablement around pidmap_lock Message-ID: <20250202135503.4e377fb0@pumpkin> In-Reply-To: References: <20250201163106.28912-1-mjguzik@gmail.com> <20250201163106.28912-7-mjguzik@gmail.com> <20250201181933.07a3e7e2@pumpkin> <20250201215105.55c0319a@pumpkin> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 8F4F240008 X-Stat-Signature: ohn8mf3rdgkcbzkzy3ojmm5s3qz3kzq1 X-Rspam-User: X-HE-Tag: 1738504506-510863 X-HE-Meta: U2FsdGVkX1+1QOikmBBYvydLWDwMPOUpnp5hFYScBU7dl6+64Bujai+nNZ7ZlZMfTGNEwt8Z2Uw88OhVnO++RBB82APWSKwiKKf2bS7psddc2KOUtBkpNx2BT4gFLe3nT7zjW5W4u8cJQRvAEd+dAZiOpKPVHhromW0htqb5eqbDg6+17+pazzjtr7gOvDg2rZgHOlnbz+ASV9u/N4GF9wTLLI5erfpXMm0QCWC4aMvGlX8VyO45PDaWSjK5+GL4M7VA8OmA/leXQZTXM3d+vvA4pSbHCrCoJPxLaziUmUWa+EkSv3TsRARfE6pnaCZVvlR9eiR7bVjNtpb+yTvWSgCCexyWMqxWAJ0+/p5IMfJOO7rmDEBqW17p5iU3hOiwns8CqVyTdoNw1m11b8Ob2QYT2v5LU8m5GhwCI9jF+rY9Y9Ez+YRqNPWlg5w9bmHXguBZY6Y9sZ2QsIzEQ4cbomfgyt1F4yjxQMcbktAXgke2kzuqnXuAEsiPDspEcX9fgczAum8qnn4XGQkIZFFV3iM4xNadiS7qtkQ8HFOgmwbE6+DOXOhR29eugKHhh3KAkaZ/uZrWbT/F1AaU/iAZ9YZgVmKthUg3/eQzmKo0CSeG9aaT1qoLAOqWaqowF83R/FN9GDamlok9nBJO14ywJJK+YsSF7Xv+IbM05g1Lfp/9yQ4713tFMKsyPxxInwsdqul/++d8OUbESRjJhbYxQ8Xo/xa46+ztbbN5upmdU40IH9sCHYN4NhjvuQt1QRCTqJ64NLiRMq4d1D1vEG+hOVa7rNnbQXEJBadykqQsC5QisaZBS3kRW0+MnYgya7mIM49KFp8x0IY/RJ3toukbcV/I+S7cPlOzXwWi/BNwF1BIJrWzX/7yVijirh1ltAVfdu/L7aFVU00AifJrZwaWCS9NPp8pJVl6J4v4mm7/+oNdtsBCQHpPKacVbwtND7vH6R6oETR92V0SvI53flQ TjJiRGKd Jf+RVQl1p18tCgfhZ1OVU1u+QE2sLrBSggWuz5G3qX60O94+JQI3IboVIaarv3e9OkpxVOUjJDx7HanNwiKjeDF0Ma1EfkiRRCBUkVnV1TtY9Olumvgi+UvVA66OdenvqA+81gxxhrriafou+l8zE/LlSodZ57Kq06b6x51Ik/JWYcMuPImUIpjEiQVxrq9qW9YUR+iEHZ18B0DrnZCes3ug9Mie0deMp6YzVJuRJrsFZXUgiy+nGmlVqMj2LsAIn6mTc0fnBn1Csq8z52kM9BpEprNQeedKgnKmWY7xUQ5bj8Pb55h5YW6t4LQMziHnAuorZsysm4E/f4bNA4an2DGDs1Jf9+28YAtmzAod0cgc5QWOMWc0uwaLhN/VCvDgWDDxjBpK+ZPJstNhScu6arfr07p3xv+HzqEaLhEP7N8d3Y8+iI63HS6neu8YjBaXVUeKPUOjTzKWygZdUfdWjuF0ic4x0vxFAF7y/W+fpR2xCyvxZhjGdXHpQ+A== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Sat, 1 Feb 2025 22:00:06 +0000 Matthew Wilcox wrote: > On Sat, Feb 01, 2025 at 09:51:05PM +0000, David Laight wrote: > > I'm not sure what you mean. > > Disabling interrupts isn't as cheap as it ought to be, but probably isn't > > that bad. > > Time it. You'll see. The best scheme I've seen is to just increment a per-cpu value. Let the interrupt happen, notice it isn't allowed and return with interrupts disabled. Then re-issue the interrupt when the count is decremented to zero. Easy with level sensitive interrupts. But I don't think Linux ever uses that scheme. > > > So while this is indeed a tradeoff, as I understand the sane default > > > is to *not* disable interrupts unless necessary. > > > > I bet to differ. > > You're wrong. It is utterly standard to take spinlocks without > disabling IRQs. We do it all over the kernel. If you think that needs > to change, then make your case, don't throw a driveby review. > > And I don't mean by arguing. Make a change, measure the difference. The analysis was done on some userspace code that basically does: for (;;) { pthread_mutex_enter(lock); item = get_head(list); if (!item) break; pthead_mutex_exit(lock); process(item); } For the test there were about 10000 items on the list and 30 threads processing it (that was the target of the tests). The entire list needs to be processed in 10ms (RTP audio). There was a bit more code with the mutex held, but only 100 or so instructions. Mostly it works fine, some threads get delayed by interrupts (etc) but the other threads carry on working and all the items get processed. However sometimes an interrupt happens while the mutex is held. In that case the other 29 threads get stuck waiting for the mutex. No progress is made until the interrupt completes and it overruns the 10ms period. While this is a userspace test, the same thing will happen with spin locks in the kernel. In userspace you can't disable interrupts, but for kernel spinlocks you can. The problem is likely to show up as unexpected latency affecting code with a hot mutex that is only held for short periods while running a lot of network traffic. That is also latency that affects all cpu at the same time. The interrupt itself will always cause latency to one cpu. Note that I also had to enable RFS, threaded NAPI and move the NAPI threads to RT priorities to avoid lost packets. The fix was to replace the linked list with an array and use atomic increment to get the index of the item to process. David