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 D8F0CC4332F for ; Tue, 1 Nov 2022 15:53:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231537AbiKAPxa (ORCPT ); Tue, 1 Nov 2022 11:53:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34260 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230370AbiKAPx0 (ORCPT ); Tue, 1 Nov 2022 11:53:26 -0400 Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com [IPv6:2607:f8b0:4864:20::b2a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DA3492A7 for ; Tue, 1 Nov 2022 08:53:24 -0700 (PDT) Received: by mail-yb1-xb2a.google.com with SMTP id g127so9259111ybg.8 for ; Tue, 01 Nov 2022 08:53:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=OoqeNhyztxMh+aSsch8I+eD3VAvwBaYIfKxYJbYWvvc=; b=D5z8nU4FBPzjFefdFpz9+6gqBMRN+wgc7hfG8ROciZ89FHqpoW5Rjv6794zfagt9V4 NW9CdQa+hVVQoXPyRZPvw9hl0txCBCNSteyppqHHuxRhPFRYV84zZCQgXPde23wJKTiI /cOVmddaJUCJcX5cR5S5oZL/ZlaEOQYmaFlvoO5D+8GaZlxajYE4LGMmFwb2ocFq5Eh5 mzLWOtQ4sMO1xACOdzM7Z8AGSkNsQxvp5srDjMIJVFLF+LqFiD5zfEQCDqeIC7qsoFzX JXiHrGGUjtpVMMoeXB4gK+uzzVxC1U0zI78LiJpWCpyCg0mPcaYWouVyCGylrwwfvk+7 SbdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=OoqeNhyztxMh+aSsch8I+eD3VAvwBaYIfKxYJbYWvvc=; b=YOV0ptmky1cKjfU7Juyrw6+F355xZiKcm3OUURALQTr8PbYFyMtgeW4YFutY+0uXsR aBRLeVO4vAz4xphFmfduHFa+WqOkhHrvGkeFsKi11ex4oVKZFdeE7M09pU1cxITZ4pOA fZ+6cDH+SJ/3M1MrAKQ4H4M/4jK48It0X+WqL1T8+y+fqtvfPR4mBXpBZeIZi9v/I9GB NM0LxULhyjIZjhefidsCxUkJGmMDihfUNOrAQ97qp7vHQMgoRHLl2vk7ul0UyHbfK2tk 3RblUC0AlxL+xLF/AytSs732qJEKmuxKAnQk2wBHWJGkuMNjQKaxhPpmzJLmNJVeynrY 5LHw== X-Gm-Message-State: ACrzQf3uCwPkON2sT+f/OC2Ip72b4Sm0M6k1JMBmTjs0XIgYYmEHNaGt 6mYm6VLJSYFbz/8ScuTekRwK00rbtS6Bz0CR87p+nQ== X-Google-Smtp-Source: AMsMyM4ZFczLE3qSUoRMUHLhkKihEjBCXVb0KD21pHAYskWZsp/tmZakL3aeLNhu/bURKXIk1yFlAMo7lVuBEuy5FFs= X-Received: by 2002:a5b:443:0:b0:6bc:e3d1:8990 with SMTP id s3-20020a5b0443000000b006bce3d18990mr19926712ybp.191.1667318004077; Tue, 01 Nov 2022 08:53:24 -0700 (PDT) MIME-Version: 1.0 References: <81a7b4f6-fbb5-380e-532d-f2c1fc49b515@intel.com> <76bb4dc9-ab7c-4cb6-d1bf-26436c88c6e2@arm.com> <835d769b-3662-7be5-dcdd-804cb1f3999a@arm.com> <715e4123-fdb3-a71e-4069-91d16a56a308@arm.com> <317b4a96-f28d-aab5-57cc-f0222b7e4901@intel.com> <08c0e91a-a17a-5dad-0638-800a4db5034f@intel.com> In-Reply-To: From: Peter Newman Date: Tue, 1 Nov 2022 16:53:12 +0100 Message-ID: Subject: Re: [RFD] resctrl: reassigning a running container's CTRL_MON group To: Reinette Chatre Cc: James Morse , Tony Luck , "Yu, Fenghua" , "Eranian, Stephane" , "linux-kernel@vger.kernel.org" , Thomas Gleixner , Babu Moger , Gaurang Upasani Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 1, 2022 at 4:23 PM Peter Newman wrote: > Yes it looks like the task's rq_lock would provide the necessary > ordering. It's not feasible to ensure the IPI arrives before the target > task migrates away, but the task would need to obtain the same lock in > order to migrate off of its current CPU, so that alone would ensure the > next migration would observe the updates. > > The difficulty is this lock is private to sched/, so I'd have to propose > some API. Actually it looks like I can just use task_call_func() to lock down the task while we do our updates and decide if or where to send IPIs. That seems easy enough. -Peter