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 42CAAC76196 for ; Fri, 7 Apr 2023 03:54:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A2E826B0075; Thu, 6 Apr 2023 23:53:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9DE7E6B0078; Thu, 6 Apr 2023 23:53:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8CCC56B007B; Thu, 6 Apr 2023 23:53:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 774FC6B0075 for ; Thu, 6 Apr 2023 23:53:59 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 4DFDAAC081 for ; Fri, 7 Apr 2023 03:53:59 +0000 (UTC) X-FDA: 80653226598.04.BA63510 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf09.hostedemail.com (Postfix) with ESMTP id 56E9514000C for ; Fri, 7 Apr 2023 03:53:57 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=BwpEROdR; spf=none (imf09.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680839637; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=RNHjRAVOmVSuegrqYJy+dt/EyRDw2CigzlLcuxrW8EU=; b=iOtYcDbvAc5Iu2e+R4C+Y+GNdnDJ0+JnJg1CDLRVFZa2NDdXhRap4V6srYhTH8wo5Bhkxn TZbBiq1X1xAf6scUEPBxpCoOIgbrIONe48hmrLdxTveac7cfVB6NxYieikFBpoGkZWur1w vQtRYRxWkNbyrfocLmaL48/oPLhTSSs= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=BwpEROdR; spf=none (imf09.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680839637; a=rsa-sha256; cv=none; b=vUferDZXKQLkRXRQGv1fHhMx/6IlCJAL7xxZLlRYsrB9JeRlCXPHaS1w7Sxbdkpy2AsBfx cct2eHibAfMA1hgPZjXTXXd4YiAloLW0aH8xyK/aDsuZwRUzfEWtq1c7oWlsNCROcGugM8 mqZKGXYLkz5C1KdHl7TAl/UiGXILX/U= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.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; bh=RNHjRAVOmVSuegrqYJy+dt/EyRDw2CigzlLcuxrW8EU=; b=BwpEROdRzotoV2ZDg2xVxWLS+5 vOPwnteZ4eSQP6Wiblm3TCtCOzTCA1vx1GcafvFzPJv14tuy/aKacRwj6mCeKD4NST0eCf5MofPbg JCExdJHvTWEnEcek5M3anciJA3BeodtVJ94d4V6gCtaKPgOM4gGNrDCkA9zAGuVzX27poE4UFt5i/ cmUvjWws7LxyIfHlv5joASpprutm0ZDT7olHKn33CVPTuYChNlnwuimZrgfQatAHAgKsApd372UCx DQYgA2wTenQpOn7WdUAWG3hUHedDQrz1dMIwoYUyzN/CpBJmbewSI96YXP6yVXH+NkqO3OPJk9MSK TzHSruMg==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1pkdAF-000VM0-W4; Fri, 07 Apr 2023 03:53:28 +0000 Date: Fri, 7 Apr 2023 04:53:27 +0100 From: Matthew Wilcox To: Hillf Danton Cc: Sebastian Andrzej Siewior , linux-kernel@vger.kernel.org, "Eric W. Biederman" , Ingo Molnar , Mel Gorman , Oleg Nesterov , Peter Zijlstra , Thomas Gleixner , Vincent Guittot , linux-mm@kvack.org, Linus Torvalds Subject: Re: [PATCH v4] signal: Let tasks cache one sigqueue struct. Message-ID: References: <20230406194004.KP1K6FwO@linutronix.de> <20230407000306.940-1-hdanton@sina.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230407000306.940-1-hdanton@sina.com> X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 56E9514000C X-Stat-Signature: aofjz8haxacddtwmsgb6kuydw6mbitw6 X-Rspam-User: X-HE-Tag: 1680839637-687769 X-HE-Meta: U2FsdGVkX19IExcIiLDqBIqYeW0gGHx/y65LKfXdoyyX9WtAoBV8sBtxkkPGCk7UX64+U23QEqBo96ugLzQPGQZYw8WuX4CmmzBHsZyxpqoTUTex4muhq8uFOIO7MpMd9sBvuAeAb1fOjzv3aYN0ctTJRURjws6TA+2Ue9PuIyR+s/gLMCWUGhV/O/SIZYm0uaO7/Uz/0aAwHYAKLzVVSSWq6S6OEz9Jgq9fvGmK1suiuf7rE+PiEROzS+pbeGQwsGEcbAOWeIVCwYlg3zje9nkMDJ+7/sLyu1U4WPzT4ORY9HJeDCbWlLY4drQoSgo7YVdamclZVSDsH1DPIbNFR5caN5UimIR3oGxB0Axs5hFoCxd/0WBaxVpmbpI8/SqyfScFH8yG1Cu6yCsJ19qIelVoWFh943dT6kfd6+PykQDO07RSjwzrP6retLJYMm+iku7CDOrYXtQ7HoJORZ08g7qZXF3cTslh/VBqmJzUU+3+JxAawU8FTCjhwxWde8ATBBKyaGE25WYvhlhndnWOL6Iw2BOQIEe4OrZT6xP6SfKHs09YGJ35JassjXn07TgqjZA3wnWNarNRrEG8vs9+140fh4Vw/T+8S68cBu3005d2xPB1JZ6ajSAHIKK/59YfLmiYxHLlAQ1xAjmbG4yT/wpsMQVARxrBAmGKKTex7JU7Tv8IOG0Q+5lPHOVStp3/17mAtlfT3SkTGgbCsh260WvXmZ0aEuhGnb+VPWLMXHxWSOPKvexpNcL2g5+1Pv8vkPRkZuFfrPfF+az4EcYIMLgcE1rh/LM3GWfcPpPQswtJ8Ou9OrYl8B0rrWi6bbf6DgJPpo1CUd6JVhFvSpWZDQTqjoyUtmFGDSLpeBQTQjHSapdvYTvVw+CZVCq69YSNj9oA3MTRBGCd2IR6xkXBSc3KdwgTSU8utaJDJo41vDP055BnkqU67fEy+lfEXwIe+KWoRkGnLuDXQ1ENJLF ezWXran6 EvuCyhKdXPWRaUzzyLJKWVc3Hifila39K11g9+LD2jv59un6wusSqDrrDkRdITN7hbMm2MmFaXsc0UTuduzyHNB3HieAjGs375JnhE+p+wnVpSzFErmrguMuZ/0TG2TXcbsSpSdNDIobUpmt2JbCJoFBPT6BgL5qPzx0X 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: On Fri, Apr 07, 2023 at 08:03:06AM +0800, Hillf Danton wrote: > On Thu, 6 Apr 2023 22:47:21 +0200 Sebastian Andrzej Siewior > > The sigqueue caching originated in the PREEMPT_RT tree. A few of the > > applications, that were ported to Linux, were ported from OS-9. Sending > > notifications from one task to another via a signal was a common > > communication model there and so the applications are heavy signal > > users. Removing the allocation reduces the critical path, avoids locks > > and so lowers the maximal latency of the task while sending a signal. It might lower the _average_ latency, but it certainly doesn't lower the _maximum_ latency, because you have to assume worst case scenario for maximum latency. Which is that there's no sigqueue cached, so you have to go into the slab allocator. And again, worst case scenario is that you have to go into the page allocator from there, and further that you have to run reclaim, and ... What I find odd about the numbers that you quote: > The numbers of system boot followed by an allmod kernel build: > Out of 333216 allocations, 194876 (~58%) were served from the cache. > From all free invocations, 4212 were in a path were caching is not done > and 329002 sigqueue were cached. ... is that there's no absolute numbers. Does it save 1% of the cost of sending a signal? 10%? What does perf say about the cost saved by no longer going into slab? Because the fast path in slab is very fast. It might even be quicker than your fast path for multithreaded applications which have threads running on different NUMA nodes.