Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp3414923pxb; Mon, 4 Oct 2021 01:43:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw9BTT9k8g+rKc2FL8DKWk0jHfDfEbWPaw/RbQ9mLVNPrLKqGgvma9++1+81AypTI5kug9W X-Received: by 2002:a50:cf0d:: with SMTP id c13mr15928314edk.269.1633337015648; Mon, 04 Oct 2021 01:43:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633337015; cv=none; d=google.com; s=arc-20160816; b=Fu+6/fn1BJzItdJzliqmrnqRfl3x4T8e8zldpNCDjJyFqnsuAqQUt0T310PdByAjaz UBBuwMHd+KTNP8NdErZGQa2bHYvSv8jkJoQmZYoVVGjbTmgfljOSEdcfenet1n7P2G4v MtOJSxh3IvYozYvO7NW/0BruXlhydmiEueKWGJtLr4xyjYkwOyjoobcaKZvtvUQMp9Rk t2AVs4J6DjZPc3iBXgupR8KKLEpr0Pq2LZMm7+HHPK63UdgNmPHGBZznPpqja7nBTcOb SJtl61hXfZ2T1EqUiS0ynFpr9iPXk6jN8GZMua5eEQLxWzDVEeo0CU9iBAPXaI8W4t02 3U0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=zKfDV0YNjCwsU17bwwpjgv9Pzvz+7OLk3zePGdmFYy8=; b=ROVxLzZH3Y2Gs0ZRQIq80oeZkoLHVKLwHsQfAIY1U+8adAXsCnkwxiMzBEw6PIBBVl P9grETxnO2h/Y9N7Ta3ypou3jdDAzFB51MVVrSycEpW3jiKgBnyimCjLSbtqMfziddFU 1s/UbyYlnJdyNPgBe02/ATnPuoRtH5ILkIx14TtaBDLTaEsv+B1wNiuEWbW9nJy1IwSv Yd2l0vaz4g3l7nE23wYWpgyDSnOUP/xyqnEP7R4oFPIUZeJxS5kBZYOSWojd4b/vw8bk jkz5lzILEPS1wpcCUoWDcpzEBx70rdiwlsq4UWWF0Fu/93KQ0Urg9Gnn3ceEI1O/NCgB Vl1A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=desiato.20200630 header.b=hlLS99M+; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m23si8347166eje.259.2021.10.04.01.43.12; Mon, 04 Oct 2021 01:43:35 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=desiato.20200630 header.b=hlLS99M+; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231735AbhJDIld (ORCPT + 99 others); Mon, 4 Oct 2021 04:41:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52762 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231566AbhJDIlc (ORCPT ); Mon, 4 Oct 2021 04:41:32 -0400 Received: from desiato.infradead.org (desiato.infradead.org [IPv6:2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AEC5AC061746 for ; Mon, 4 Oct 2021 01:39:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; 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=zKfDV0YNjCwsU17bwwpjgv9Pzvz+7OLk3zePGdmFYy8=; b=hlLS99M+YxsFJUfufRgK/afR0W ke9AhprYdInkVZ9Mv2erU7XbHL9jtxpzkFdrrOaSDlvyTId9EStVoWAnvVMJhG6qU9awxJHSBp6KK S95QdHlOJaVVpPJfYxFpc+nM+JHNET9gi3mmEso5KUo1Hl+a0CrVPBAS+IJbvniFo7cTPPSE0Ejxu KxWUsaWT8uXQ0iZPbNFdllxGEqkIwgZ/szqvX9YnQnGg3Pao47a0xftztbZ/Dx8iOCvbDZuNr1mUL RvDgrbK8eUjfbT4ApAnZA4oiEH4ZdqIpIzzYsmcFmDW+b0mMD/6TFOycb5ljUIzK9xOyA6oWgH0OW AN3npNZw==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1mXJVS-007nRF-IH; Mon, 04 Oct 2021 08:39:30 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id AB97A3002DE; Mon, 4 Oct 2021 10:39:29 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 557BF20A660F3; Mon, 4 Oct 2021 10:39:29 +0200 (CEST) Date: Mon, 4 Oct 2021 10:39:29 +0200 From: Peter Zijlstra To: Tvrtko Ursulin Cc: Intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Tvrtko Ursulin , Ingo Molnar , Juri Lelli , Vincent Guittot Subject: Re: [RFC 1/6] sched: Add nice value change notifier Message-ID: References: <20210930171552.501553-1-tvrtko.ursulin@linux.intel.com> <20210930171552.501553-2-tvrtko.ursulin@linux.intel.com> <20210930183316.GC4323@worktop.programming.kicks-ass.net> <4aca656d-678f-4d61-38a4-d2e7a8fd89ab@linux.intel.com> <5c71ec04-9148-0587-c495-11dbd8f77d67@linux.intel.com> <01a968c9-c427-f4c7-44d5-2f47f939f9eb@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01a968c9-c427-f4c7-44d5-2f47f939f9eb@linux.intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 04, 2021 at 09:12:37AM +0100, Tvrtko Ursulin wrote: > On 01/10/2021 16:48, Peter Zijlstra wrote: > > Hmm? That's for normalize_rt_tasks() only, right? Just don't have it > > call the notifier in that special case (that's a magic sysrq thing > > anyway). > > You mean my talk about tasklist_lock? No, it is also on the syscall part I > am interested in as well. Call chain looks like this: Urgh, I alwys miss that because it lives outside of sched.. :/ > sys_setpriority() > { > ... > rcu_read_lock(); > read_lock(&tasklist_lock); > ... > set_one_prio() > set_user_nice() > { > ... > task_rq_lock(); > -> my notifier from this RFC [1] > task_rq_unlock(); > -> I can move the notifier here for _some_ improvement [2] > } > ... > read_unlock(&tasklist_lock); > rcu_read_unlock(); > } > > So this RFC had the notifier call chain at [1], which I understood was the > thing you initially pointed was horrible, being under a scheduler lock. > > I can trivially move it to [2] but that still leaves it under the tasklist > lock. I don't have a good feel how much better that would be. If not good > enough then I will look for a smarter solution with less opportunity for > global impact. So task_list lock is pretty terrible and effectively unbound already (just create more tasks etc..) so adding a notifier call there shouldn't really make it much worse.