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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 164FDC433F5 for ; Wed, 15 Dec 2021 18:19:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 60FEB6B0073; Wed, 15 Dec 2021 13:19:20 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5BF4F6B0074; Wed, 15 Dec 2021 13:19:20 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 460006B0075; Wed, 15 Dec 2021 13:19:20 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0005.hostedemail.com [216.40.44.5]) by kanga.kvack.org (Postfix) with ESMTP id 38E496B0073 for ; Wed, 15 Dec 2021 13:19:20 -0500 (EST) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id F38D87FAAA for ; Wed, 15 Dec 2021 18:19:09 +0000 (UTC) X-FDA: 78920840418.26.7D452E4 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf23.hostedemail.com (Postfix) with ESMTP id 733BD140002 for ; Wed, 15 Dec 2021 18:19:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; 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=zmFY3Gs53FyRCPoRjth8UcDlb/32jRwmwTYyj2vOBUo=; b=LRIKOnjS723sZGnU7NLgsxvD1U 4y4Xc1ywEcIKnMpZ2HnWPWW8h4WLF5TFDB5CmkQmN5YOiC60be9chJ+t4lvcbSZ949lwXZhJHK7N4 rdQvnwNQJmze7vGC8ymwTTxhiMW1ZkP0MdSBcKuywW08pWSV/QOJN4T8+13Yvd8bAWAMjw33YDVDZ PNyme0HTyDKFO44pT8Heo9E34DnYK3q7MoP+j2eNGRaDzfaxtmq7Y8wM353OSK4+GyGSzdIWbCYjA SuQjvgM9s31JXx7cantn7hj4TbBZWP6PLyndtgf93g4rNWFJ43+MUtSqrQTmkmmh+GR9eAwFUFMXO AK5Srjow==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1mxYre-00Etns-4Q; Wed, 15 Dec 2021 18:18:55 +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 (4096 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 29DA6300348; Wed, 15 Dec 2021 19:18:53 +0100 (CET) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 0C1A2200C2286; Wed, 15 Dec 2021 19:18:53 +0100 (CET) Date: Wed, 15 Dec 2021 19:18:53 +0100 From: Peter Zijlstra To: Peter Oskolkov Cc: Ingo Molnar , Thomas Gleixner , juri.lelli@redhat.com, Vincent Guittot , dietmar.eggemann@arm.com, Steven Rostedt , Ben Segall , mgorman@suse.de, bristot@redhat.com, Linux Kernel Mailing List , Linux Memory Management List , linux-api@vger.kernel.org, x86@kernel.org, Paul Turner , Peter Oskolkov , Andrei Vagin , Jann Horn , Thierry Delisle Subject: Re: [RFC][PATCH 0/3] sched: User Managed Concurrency Groups Message-ID: References: <20211214204445.665580974@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 733BD140002 X-Stat-Signature: hsebxgry7fckyjzm1c48pccxekpobyt6 Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=LRIKOnjS; spf=none (imf23.hostedemail.com: domain of peterz@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=peterz@infradead.org; dmarc=none X-HE-Tag: 1639592344-352816 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Dec 15, 2021 at 09:56:06AM -0800, Peter Oskolkov wrote: > > Right, so the problem I'm having is that a single idle server ptr like > > before can trivially miss waking annother idle server. > > I believe the approach I used in my patchset, suggested by Thierry > Delisle, works. > > In short, there is a single idle server ptr for the kernel to work > with. The userspace maintains a list of idle servers. If the ptr is > NULL, the list is empty. When the kernel wakes the idle server it > sees, the server reaps the runnable worker list and wakes another idle > server from the userspace list, if available. This newly woken idle > server repoints the ptr to itself, checks the runnable worker list, to > avoid missing a woken worker, then goes to sleep. > > Why do you think this approach is not OK? Suppose at least 4 servers, 2 idle, 2 working. Now, the first of the working servers (lets call it S0) gets a wakeup (say Ta), it finds the idle server (say S3) and consumes it, sticking Ta on S3 and kicking it alive. Concurrently and loosing the race the other working server (S1) gets a wake-up from Tb, like said, it lost, no idle server, so Tb goes on the queue of S1. So then S3 wakes, finds Ta and they live happily ever after. While S2 and Tb fail to meet one another and both linger in sadness.