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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A653EC433E0 for ; Thu, 4 Mar 2021 19:06:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7354664F72 for ; Thu, 4 Mar 2021 19:06:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237150AbhCDTFY convert rfc822-to-8bit (ORCPT ); Thu, 4 Mar 2021 14:05:24 -0500 Received: from out03.mta.xmission.com ([166.70.13.233]:55716 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236228AbhCDTEy (ORCPT ); Thu, 4 Mar 2021 14:04:54 -0500 Received: from in02.mta.xmission.com ([166.70.13.52]) by out03.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1lHtGb-00ASEp-EP; Thu, 04 Mar 2021 12:04:09 -0700 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=fess.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1lHtGa-002EOH-DL; Thu, 04 Mar 2021 12:04:09 -0700 From: ebiederm@xmission.com (Eric W. Biederman) To: Thomas Gleixner Cc: Sebastian Andrzej Siewior , linux-kernel@vger.kernel.org, Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Daniel Bristot de Oliveira , Oleg Nesterov , Matt Fleming References: <20210303142025.wbbt2nnr6dtgwjfi@linutronix.de> <20210304081142.digtkddajkadwwq5@linutronix.de> <87tupr55ea.fsf@nanos.tec.linutronix.de> Date: Thu, 04 Mar 2021 13:04:08 -0600 In-Reply-To: <87tupr55ea.fsf@nanos.tec.linutronix.de> (Thomas Gleixner's message of "Thu, 04 Mar 2021 16:02:05 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-XM-SPF: eid=1lHtGa-002EOH-DL;;;mid=;;;hst=in02.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX18R52oqQneu5np0N/5Uc8Jp1bSLt8e3Wso= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH] signal: Allow RT tasks to cache one sigqueue struct X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Thomas Gleixner writes: > On Thu, Mar 04 2021 at 09:11, Sebastian Andrzej Siewior wrote: >> On 2021-03-03 16:09:05 [-0600], Eric W. Biederman wrote: >>> Sebastian Andrzej Siewior writes: >>> >>> > From: Thomas Gleixner >>> > >>> > Allow realtime tasks to cache one sigqueue in task struct. This avoids an >>> > allocation which can increase the latency or fail. >>> > Ideally the sigqueue is cached after first successful delivery and will be >>> > available for next signal delivery. This works under the assumption that the RT >>> > task has never an unprocessed signal while a one is about to be queued. >>> > >>> > The caching is not used for SIGQUEUE_PREALLOC because this kind of sigqueue is >>> > handled differently (and not used for regular signal delivery). >>> >>> What part of this is about real time tasks? This allows any task >>> to cache a sigqueue entry. >> >> It is limited to realtime tasks (SCHED_FIFO/RR/DL): >> >> +static void __sigqueue_cache_or_free(struct sigqueue *q) >> +{ >> … >> + if (!task_is_realtime(current) || !sigqueue_add_cache(current, q)) >> + kmem_cache_free(sigqueue_cachep, q); >> +} > > We could of course do the caching unconditionally for all tasks. Is there any advantage to only doing this for realtime tasks? If not it probably makes sense to do the caching for all tasks. I am wondering if we want to count the cached sigqueue structure to the users rt signal rlimit? Eric