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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 8AB62C433E1 for ; Wed, 8 Jul 2020 21:45:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5B5E8206C3 for ; Wed, 8 Jul 2020 21:45:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726278AbgGHVpW (ORCPT ); Wed, 8 Jul 2020 17:45:22 -0400 Received: from foss.arm.com ([217.140.110.172]:39850 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725446AbgGHVpV (ORCPT ); Wed, 8 Jul 2020 17:45:21 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C1BF91FB; Wed, 8 Jul 2020 14:45:20 -0700 (PDT) Received: from e113632-lin (e113632-lin.cambridge.arm.com [10.1.194.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 5996C3F887; Wed, 8 Jul 2020 14:45:18 -0700 (PDT) References: <20200706142839.26629-1-qais.yousef@arm.com> <20200706142839.26629-2-qais.yousef@arm.com> <20200707093447.4t6eqjy4fkt747fo@e107158-lin.cambridge.arm.com> <20200707123640.lahojmq2s4byhkhl@e107158-lin.cambridge.arm.com> <20200708130831.4oaukv65hbano3j7@e107158-lin> User-agent: mu4e 0.9.17; emacs 26.3 From: Valentin Schneider To: Qais Yousef Cc: Ingo Molnar , Peter Zijlstra , Doug Anderson , Jonathan Corbet , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Luis Chamberlain , Kees Cook , Iurii Zaikin , Quentin Perret , Patrick Bellasi , Pavan Kondeti , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH v6 1/2] sched/uclamp: Add a new sysctl to control RT default boost value Message-ID: In-reply-to: <20200708130831.4oaukv65hbano3j7@e107158-lin> Date: Wed, 08 Jul 2020 22:45:12 +0100 MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/07/20 14:08, Qais Yousef wrote: > On 07/08/20 12:05, Valentin Schneider wrote: >> > AFAIU rcu_read_lock() is light weight. So having the protection applied is more >> > robust against future changes. >> >> So I think the one thing you win by having this dance with mb's and the >> suggested handling of the task list is that you do not need any >> rcu_synchronize() anymore. Both approaches have merit, it's just that the >> way I understood the suggestion to add sched_post_fork() was to simplify >> the ordering of the update with the aforementioned scheme. > > The synchronize_rcu() is not for sched_post_fork(). It is to deal with the > preemption problem. > >> >> > >> >> >> >> sched_post_fork() being preempted out is a bit more annoying, but what >> >> prevents us from making that bit preempt-disabled? >> > >> > preempt_disable() is not friendly to RT and heavy handed approach IMO. >> > >> >> True, but this is both an infrequent and slow sysctl path, so I don't think >> RT would care much. > > There's an easy answer for that. But first I'm not sure what problem are we > discussing here. > > What is the problem with rcu? And how is preempt_disable() fixes it or improves > on it? > Minimizing the races we have to think and take care of would make this easier to review and maintain. That's what I was suggesting with getting entirely rid of the preemption+update issue and having only the update+forkee race to take care of, which is IMO fairly straightforward to reason about on its own. That said, you're driving the thing, and I'm not, so I'll trust your judgement here. > Thanks