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 5C616C433EF for ; Wed, 15 Dec 2021 17:56:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ED9F36B0073; Wed, 15 Dec 2021 12:56:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E891D6B0074; Wed, 15 Dec 2021 12:56:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D516C6B0075; Wed, 15 Dec 2021 12:56:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0150.hostedemail.com [216.40.44.150]) by kanga.kvack.org (Postfix) with ESMTP id C7AA46B0073 for ; Wed, 15 Dec 2021 12:56:28 -0500 (EST) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 96D558249980 for ; Wed, 15 Dec 2021 17:56:18 +0000 (UTC) X-FDA: 78920782836.08.EC891DC Received: from mail-ua1-f54.google.com (mail-ua1-f54.google.com [209.85.222.54]) by imf24.hostedemail.com (Postfix) with ESMTP id 982D8180017 for ; Wed, 15 Dec 2021 17:56:15 +0000 (UTC) Received: by mail-ua1-f54.google.com with SMTP id ay21so42389831uab.12 for ; Wed, 15 Dec 2021 09:56:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posk.io; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ys3rZNuX7+z7pA4D/KdILKC/mW3vMwpvwDb3wE/01Rk=; b=WW/hDoEwCR1rjxM+F7Yqu7cbwjS2D1bqvjEDmHgeoNa4PpqzkK/Wtz52xdZLCWaYoc 6Pn5GlBJr1vQSqOPG7HIqznF6eHy8RNiaB8KcPFORAnkybihRPqcWot4wmmdx/Sn7giF 6ksUoQLeqZS/6NQfhsRKADgceL1NH3EXpvitsHQ11ncUc0WYkenrnitfsLgT+xhwx0EQ QIifb4vEkoZCZJk1L8dL5YNogD1RSRGVUVAizVq+NA4A9xM0nkT9E2qmYtgGtDazpxWK 2K0Fb65gE2iQADFX90bH5+pnqPBE9urVbakB+se5A8QEswecS3Mhbr29o5Nd67CNKEqq wbXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ys3rZNuX7+z7pA4D/KdILKC/mW3vMwpvwDb3wE/01Rk=; b=EkZZkRxuTDKaj+6dDuelBfuIRBagiTZLBbDBpW68vnyHPOvlXQ4M7MJbMvBUzFOl9p 84MZZzIK33lbXJMDztOKBB04a90qggoyYWTZe17e1vOn8dbMp8TCSyuLKn+LhpnINKBj gtDVu/VSsSPXngwSP2dk6W1NAz5ePUrubIwUVlxL4ZrdKCYjWs9ard2MZcKHtsUyVDY/ F8wb3NNIpXIf2zH0qk3MRaAVauOUk/z/dUnM2n9+nRSlgaDS04p3DSSEbFApwOcmPXMk 8NbQevl28RCfxupB2wd9actCMp13OS4j0hME1H60Syw63BcB1Iu9yGNA66zV2i/v6IPd LT4w== X-Gm-Message-State: AOAM5301GJyXCj7pUKDrsTXDTRmGS+67FZvVDvAz7wXo/ysvopbS6cUn eNVilHgDTwUsR895uirkhTHLKauGXWiXzKRbBvm2hg== X-Google-Smtp-Source: ABdhPJy+0ibS31bqjUgXJDh5pEyKbSWrcOOg1QLNTZcvBmNYNGL0ZuDRxO8hqcH3gGNI1DLlIUcWmmw2XfEKcGTSo/Q= X-Received: by 2002:a9f:218c:: with SMTP id 12mr10203394uac.71.1639590977230; Wed, 15 Dec 2021 09:56:17 -0800 (PST) MIME-Version: 1.0 References: <20211214204445.665580974@infradead.org> In-Reply-To: From: Peter Oskolkov Date: Wed, 15 Dec 2021 09:56:06 -0800 Message-ID: Subject: Re: [RFC][PATCH 0/3] sched: User Managed Concurrency Groups To: Peter Zijlstra 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 Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 982D8180017 X-Stat-Signature: ky1pfteqbpthqu994kjoidna4zio3c9p Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=posk.io header.s=google header.b="WW/hDoEw"; spf=pass (imf24.hostedemail.com: domain of posk@posk.io designates 209.85.222.54 as permitted sender) smtp.mailfrom=posk@posk.io; dmarc=none X-HE-Tag: 1639590975-199706 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 2:06 AM Peter Zijlstra wrote: > > On Tue, Dec 14, 2021 at 07:46:25PM -0800, Peter Oskolkov wrote: > > On Tue, Dec 14, 2021 at 12:55 PM Peter Zijlstra wrote: > > > > > > Hi, > > > > > > This is actually tested code; but still missing the SMP wake-to-idle machinery. > > > I still need to think about that. > > > > Thanks, Peter! > > > > At a first glance, your main patch does not look much smaller than > > mine, and I thought the whole point of re-doing it was to throw away > > extra features and make things smaller/simpler... > > Well, simpler was the goal. I didn't really focus on size much. It isn't > really big to begin with. > > But yes, it has 5 hooks now, 3 syscalls and lots of comments and all > that under 900 lines, not bad I'd say. My patchset had three hooks and two syscalls, and fewer new fields added to task_struct... And similarly around 900 lines on the kernel side in the main patch. So I am not sure why you believe that your approach is simpler, unless there was something fundamentally wrong with my approach. But tglx@ looked into it, and his remarks were more about comments and the commit message and smaller things at a function level, like an unneeded goto, than about the overall design... > > Also I think you wanted something like this? I'm not sure of the LAZY > name, but I can't seem to come up with anything saner atm. > [...] > /* > + * Enqueue tsk to it's server's runnable list and wake the server for pickup if > + * so desired. Notable LAZY workers will not wake the server and rely on the > + * server to do pickup whenever it naturally runs next. No, I never suggested we needed per-server runnable queues: in all my patchsets I had a single list of idle (runnable) workers. [...] >From another message: >> Anyway, I'll test your patchset over the next week or so and let you >> know if anything really needed is missing (other than waking an idle >> server if there is one on a worker wakeup; this piece is definitely > needed). > 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?