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 83201C2BB41 for ; Tue, 16 Aug 2022 22:20:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237971AbiHPWUJ (ORCPT ); Tue, 16 Aug 2022 18:20:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43890 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238053AbiHPWTY (ORCPT ); Tue, 16 Aug 2022 18:19:24 -0400 Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BF3A17AC3A; Tue, 16 Aug 2022 15:19:10 -0700 (PDT) Received: by mail-pj1-x102c.google.com with SMTP id e8-20020a17090a280800b001f2fef7886eso175402pjd.3; Tue, 16 Aug 2022 15:19:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc; bh=v/EIdBGUkUPtNpLpVOdmRMecyshYK7WIwF9D88OOScU=; b=XFz549JzgGby3QShSMg1u6ld0qYxrMD3+idlLFNetfD3Uf4CUVmSJzQwu21B0nSuY3 DE4olgojem8eez9w5KVGDNKI9NvFlyOpx319HD1Xz0JPYqZ7GtDaO4Vyu517VUEk0vBa 3EPbHmc4qV8pUgXU3pMJS7zvviFi4hykmH28LUfjweBN4/f1jde/ZTjmWze/tOVxcjiD 4wVtggFwXqgarGqZBPJL4V5dNiKgZShkmuN19HOl8yD0CjcppHuDpJIaW2fOtUgfImf7 O+dicxS87PkLT0yR/gQzPEFBhH8VvmUxwvw6Z992mJ3fcqgr6NEgfIBdiJy8L84CfIGW C8oA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc; bh=v/EIdBGUkUPtNpLpVOdmRMecyshYK7WIwF9D88OOScU=; b=PHunzgMkHWkSQGfpeSAxGHQNhMl4Xl2Mpzn2Wgz7ucL3OaPAQDcF3L8PwXFs8UWC4b DgnIRhiQio7glLlV6Q0dPed1LpUhxxreK2VMvAgiJxjG9dOgiZYCexhN2BFvTsxO5+I6 Iiyetls0j7V9KuOoXpUK6Lby9aN2ktEbJlVQqMcAjAR2TmvamBBJ7CwR31bojmagZOKc hUzAXkKHXxrq5HLeVnTAopdC0QW+G4DjjkVSOeQ/qYkbzC438W7t8851lRVxHdbGGypH MTWGYP7t1w2f/aDpbKDHGES6t9W1ObNF1+UJVLH9xRwj5Ty77GAKGnmxhyyqLoRsOIB1 nxbA== X-Gm-Message-State: ACgBeo0QYxxhwIZFHC7UarjbotFsI/0sFU0khOUh9ucz3jWQKAiaF1hX izQiOEHloUQgxB+gmGqNJCM= X-Google-Smtp-Source: AA6agR5444hR3/D5RFxnx5aA31sSW3PzrPcGowK1Az0EUVJCo7nNYyNnIRaopp2BUk8/pmHkiVzyjg== X-Received: by 2002:a17:90b:180f:b0:1f5:160c:a656 with SMTP id lw15-20020a17090b180f00b001f5160ca656mr693043pjb.193.1660688349662; Tue, 16 Aug 2022 15:19:09 -0700 (PDT) Received: from localhost ([2620:10d:c090:400::5:7229]) by smtp.gmail.com with ESMTPSA id n12-20020a170902d2cc00b0016cbb46806asm9595537plc.278.2022.08.16.15.19.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Aug 2022 15:19:08 -0700 (PDT) Sender: Tejun Heo Date: Tue, 16 Aug 2022 12:19:07 -1000 From: Tejun Heo To: Waiman Long Cc: Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Daniel Bristot de Oliveira , Valentin Schneider , Zefan Li , Johannes Weiner , Will Deacon , cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, Linus Torvalds Subject: Re: [PATCH v5 3/3] cgroup/cpuset: Keep user set cpus affinity Message-ID: References: <20220816192734.67115-1-longman@redhat.com> <20220816192734.67115-4-longman@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, On Tue, Aug 16, 2022 at 06:11:03PM -0400, Waiman Long wrote: > It is hard to synchronize different subsystems atomically without running > into locking issue. Let me think about what can be done in this case. I have a hard time seeing why this would be particularly difficult. cpuset just needs to make the latest cpumask available to sched core in an easily accessible form and whenever that changes, trigger a set_cpus_allowed call. There's no need to entangle operations across the whole subsystems. All that's needed to be communicated is the current cpumask. > Is using a sequence number to check for race with retry good enough? It seems unnecessarily fragile and complicated to me. If we're gonna change it, let's change it right. Thanks. -- tejun