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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 10C2BC4167D for ; Mon, 30 Oct 2023 18:26:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230422AbjJ3S06 (ORCPT ); Mon, 30 Oct 2023 14:26:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52302 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230299AbjJ3S0z (ORCPT ); Mon, 30 Oct 2023 14:26:55 -0400 Received: from smtpout.efficios.com (unknown [IPv6:2607:5300:203:b2ee::31e5]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 01D20C0 for ; Mon, 30 Oct 2023 11:26:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=efficios.com; s=smtpout1; t=1698690411; bh=l2toCgu+b/voI/Jn5lyU3/p8KPLU07XVGzu99iaaO2c=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=Pa07whu2anqyTYzUAqEFwV/BMkVHl6+UsZoQoBZ8ALz4q9BOdRaCjrlu56+7+278v yAgA4DdB0uLHmybpLJapRl6Lf7myiWwMFbew+TTzlk1W09tXFMKSipJC5Bm5h6oOA1 zkR655kYwxuCzaZO4qz0pLyxmOo9hb7OB7P8HFek3qRXMLvCpUo9YGrkgOL0AAOdHn maN6PF5WEE6q6QSCYl7NqlNR3LTv16B3k2IcGEKPFQffLS1gvOzdAe3SJWQBVVFwj+ yuC/+TnAge4U9ykuJDtQBkLqLplVP9wL6QFdCDpG8PTwB+5xHk/Ys4QJCxUtUqb4h8 O/uxIS7xIKDxw== Received: from [IPV6:2606:6d00:100:4000:2d85:44b8:ccb0:e487] (unknown [IPv6:2606:6d00:100:4000:2d85:44b8:ccb0:e487]) by smtpout.efficios.com (Postfix) with ESMTPSA id 4SK1vH4cyFz1Zp4; Mon, 30 Oct 2023 14:26:51 -0400 (EDT) Message-ID: Date: Mon, 30 Oct 2023 14:27:10 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [POC][RFC][PATCH v2] sched: Extended Scheduler Time Slice Content-Language: en-US To: Steven Rostedt Cc: Linus Torvalds , Peter Zijlstra , LKML , Thomas Gleixner , Ankur Arora , linux-mm@kvack.org, x86@kernel.org, akpm@linux-foundation.org, luto@kernel.org, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, mingo@redhat.com, juri.lelli@redhat.com, vincent.guittot@linaro.org, willy@infradead.org, mgorman@suse.de, jon.grimm@amd.com, bharata@amd.com, raghavendra.kt@amd.com, boris.ostrovsky@oracle.com, konrad.wilk@oracle.com, jgross@suse.com, andrew.cooper3@citrix.com, Joel Fernandes , Youssef Esmat , Vineeth Pillai , Suleiman Souhlal , Ingo Molnar , Daniel Bristot de Oliveira References: <20231025235413.597287e1@gandalf.local.home> <20231026105944.GJ33965@noisy.programming.kicks-ass.net> <20231026071413.4ed47b0e@gandalf.local.home> <7871472b-a0c4-4475-9671-69a3244f956d@efficios.com> <20231026164549.14d45c60@gandalf.local.home> <644da047-2f7a-4d55-a339-f2dc28d2c852@efficios.com> <20231027122442.5c76dd62@gandalf.local.home> <20231027124930.3753cdd4@gandalf.local.home> <20231030094508.031357b4@gandalf.local.home> <20231030141956.05661b90@gandalf.local.home> From: Mathieu Desnoyers In-Reply-To: <20231030141956.05661b90@gandalf.local.home> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2023-10-30 14:19, Steven Rostedt wrote: > On Mon, 30 Oct 2023 14:05:05 -0400 > Mathieu Desnoyers wrote: > >> If you have the nesting counter, why do you need the explicit on/off >> switch ? > > Because I gave up when I found that one of the lwlocks seemed to take a long > time (pretty much the entire test) or I couldn't find how it was unlocked > (the code isn't trivial). > > So I just made every unlock disable the extended time slot. I need to go > back and enable both a counter and an on/off as I now realize that the spin > locks (called within the lwlock) will disable the extend time before the > lwlock is released. This should work if I have the spinlocks inc and dec > (they are straight forward and all locks are associated with an easily > found unlock), and have the lwlock use bit 31 as an on/off switch. This extra on/off switch appears to be working around userspace issues. > Anyway, I would let user space decide what it wants to do, and giving it 31 > bits to say "I'm extended" and let user space come up with how it handles > those 31 bits. If this makes it into the RSEQ uapi, RSEQ should state how userspace should collaborate wrt those bits (e.g. nesting counter protocol), even though it's not a kernel ABI per se. Otherwise we'll just push this to libc to specify this, which is odd. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. https://www.efficios.com