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 BBB12C433E0 for ; Thu, 4 Mar 2021 19:02:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 78AD864F60 for ; Thu, 4 Mar 2021 19:02:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236192AbhCDTCN convert rfc822-to-8bit (ORCPT ); Thu, 4 Mar 2021 14:02:13 -0500 Received: from out02.mta.xmission.com ([166.70.13.232]:60962 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236166AbhCDTBz (ORCPT ); Thu, 4 Mar 2021 14:01:55 -0500 Received: from in01.mta.xmission.com ([166.70.13.51]) by out02.mta.xmission.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1lHtDh-00162g-HP; Thu, 04 Mar 2021 12:01:09 -0700 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=fess.xmission.com) by in01.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1lHtDc-000869-Kd; Thu, 04 Mar 2021 12:01:09 -0700 From: ebiederm@xmission.com (Eric W. Biederman) To: Sebastian Andrzej Siewior Cc: linux-kernel@vger.kernel.org, Thomas Gleixner , 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> Date: Thu, 04 Mar 2021 13:01:04 -0600 In-Reply-To: <20210304081142.digtkddajkadwwq5@linutronix.de> (Sebastian Andrzej Siewior's message of "Thu, 4 Mar 2021 09:11:42 +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=1lHtDc-000869-Kd;;;mid=;;;hst=in01.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX19FylJH7fH0IlwEew6Xhnp2mnptXINtycQ= 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 Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Sebastian Andrzej Siewior writes: > 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); > +} I see now. I was looking for it somewhere in the allocation side. Oleg's suggestion of simply adding a few additional lines to __sigqueue_free would have made this stand out more. A __sigqueue_free that takes the relevant task_struct instead of always assuming current would be nice here. >> Either the patch is buggy or the description is. Overall caching one >> sigqueue entry doesn't look insane. But it would help to have a clear >> description of what is going on. > > Does this clear things up or is my logic somehow broken here? No I just missed the task_is_realtime limitation. Eric