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 943B1C761A6 for ; Fri, 7 Apr 2023 00:03:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1522E6B0072; Thu, 6 Apr 2023 20:03:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0DBBC6B0074; Thu, 6 Apr 2023 20:03:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EBFDB6B0075; Thu, 6 Apr 2023 20:03:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id D6C586B0072 for ; Thu, 6 Apr 2023 20:03:26 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 8A4A0C0738 for ; Fri, 7 Apr 2023 00:03:26 +0000 (UTC) X-FDA: 80652645612.09.2352285 Received: from mail3-164.sinamail.sina.com.cn (mail3-164.sinamail.sina.com.cn [202.108.3.164]) by imf19.hostedemail.com (Postfix) with ESMTP id 02B331A0002 for ; Fri, 7 Apr 2023 00:03:22 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=none; spf=pass (imf19.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.164 as permitted sender) smtp.mailfrom=hdanton@sina.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680825804; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=K+3DJbhJxeOZ/4kOoL/LVeIDGROqKMj7T9+bTMA5304=; b=0lLpy0fZM2joM10MLyBvqlh2Ci/acE8NFLeEhyC2mpCkgyPoUrfgTHaF5ae6H9c/liYnDJ besCRZCtkMEm/U7wU7+UrcaRkwg0ctNDO8b6wiZ53sQ6BkdlyUR8NKtz3kTpcxZiMu1duO APVWAVf8si9iqphiwfBCe0MKw2Sz1pM= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=none; spf=pass (imf19.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.164 as permitted sender) smtp.mailfrom=hdanton@sina.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680825804; a=rsa-sha256; cv=none; b=3NixTEKP5kus/d9bTXOR/g0+bOH4P2cIQ7f+V8ynen37rBbSMcgxOZ56ilCrkFcNQ8+sqW qwAk3ZvOwX142SdRjZ35gqPY8jqy0B87kSNmfGNTGGDcwDphLO++hXtR82ONKhoJPfkpsj xiLNpmPdJ0BP9F6XsJwwP8WIc8btFdo= X-SMAIL-HELO: localhost.localdomain Received: from unknown (HELO localhost.localdomain)([114.249.59.75]) by sina.com (172.16.97.35) with ESMTP id 642F5D8C0000EB98; Fri, 7 Apr 2023 08:02:21 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com X-SMAIL-MID: 62090815074518 From: Hillf Danton To: Sebastian Andrzej Siewior Cc: 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. Date: Fri, 7 Apr 2023 08:03:06 +0800 Message-Id: <20230407000306.940-1-hdanton@sina.com> In-Reply-To: <20230406204721.A6lSYL7A@linutronix.de> References: <20230406194004.KP1K6FwO@linutronix.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: 6bcm94b1z8p9o39pzu9bqeco3cz4g6ge X-Rspamd-Queue-Id: 02B331A0002 X-HE-Tag: 1680825802-293153 X-HE-Meta: U2FsdGVkX1+3GvFy6737dBMBlWALrwpIDYCuK2OOGhPE/THN3CVDmNMaW3X/xxMcGk/z8xn8b9FwjQ2H8rsVCMtyevxTA2HyZJNxqeumrkuRmYXhxZ1Gbym+kFgE9U4SQBHBvn9OjF4Monn5R49bKb+GSzN5N3ZN+6akdpV6ES9G5BgaQGVb75LjyCMhpYLZUxK01HvYV7Lg0OMiSaWE1Q/i7phXCjDvMUSvZXO81Cqfkpop29JxZNXZ/ABPHmzpidSe+tRgbyPoV6rYWSBtAgf1HSouKdi5c5y3d3X3vBRkFWAMsJ0+ANbTGgOu6K+j1AXh7l1z0MwinPpoFAhFhdGWtrVWnkJWlD88wJ3BYq8xQQwCEb+tZlnsLFTKG78RGG6sjB968dyCT4EKueubXCu3Hih3m+RGAvd6eCZxKBC+/NVMrFVDQJMjfOFQcGeu73uifCLMI+VkvGZwNRzFZLztGOymIxrHwZJfkyCb2w/2dh5nSwt5Y8Q2Q3zsAdfLZ9eVXFPedBwNhzHVOHzh8qmY5VOEbh2AO4n3nkbzon97QB4DgGZa6LIOrhxBD0+YYIN4/RGiqslw4RyAXFjlAdER14HS0tqBLB+1GSuWrhKv3cd1iXigXZ4CGWwB3r1SukiRsFUhNwut+lu+AXcAGi3k4xMM0ONET74cHRsvoDyI3WE6pmN1r5/JM7QuuSBP8u1B94y5WVGwx84UQ5vbcClj4elzZrX4nXpIH+xf3/eMN1LzAp+MtvcyH5TsBUaxzONnn/vySZblhZFD3yu5LGP0b5eI9JQT9Qn0oPz6/SslJmQCksF9YkeTdnwAANYn1PL3saCUWB9q05Y8y1NtbxMuTaKifXjpJs1jtbe3I8SQ/0iaCmStXnGjidi5+IV7ec+aQBu5Cr8+dpj+HS+EprZ7K/qBZ/jkpAuZR2f2atUFGOX/tK/6QAU/Sv+18E9wfw5Y33gw5Vr7XnQH8gi 50ODnbo0 F4iT/0+h25VDtPnFbjKSFK544+MhZ76mdn+f3m3urF28byh5crrPQs+790qN5a5ybGZHvUyIil6Y9QUoYV1pVUIW9yffyyhh5/uQ1 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 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. This is needed only if slab does not work for you. Why not make it work better instead of peeling slab one more off just to make signal/rt richer? > > --- a/kernel/signal.c > +++ b/kernel/signal.c > @@ -432,7 +432,18 @@ static struct sigqueue * > return NULL; > =20 > if (override_rlimit || likely(sigpending <=3D task_rlimit(t, RLIMIT_SIGPE= > NDING))) { > - q =3D kmem_cache_alloc(sigqueue_cachep, gfp_flags); > + > + if (!sigqueue_flags) { > + struct sighand_struct *sighand =3D t->sighand; > + > + lockdep_assert_held(&sighand->siglock); > + if (sighand->sigqueue_cache) { > + q =3D sighand->sigqueue_cache; > + sighand->sigqueue_cache =3D NULL; > + } > + } > + if (!q) > + q =3D kmem_cache_alloc(sigqueue_cachep, gfp_flags); > } else { > print_dropped_signal(sig); > }