From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 68D601E0B9C for ; Tue, 3 Feb 2026 00:55:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770080121; cv=none; b=uOdoLAJepllATXaTa1TRiaVNy9LrwgJdPx85MJQalOrxGMgZMKP/qSEeD35rKYu/OswRgX3LH2xTsCj10u7TCe5xiXEsc9LXEWG88H1ayQdLECae/t3Pb6+yTIZE2IeitU1qVtNq2aQpPZlrwrZVSDQ48YziJ5RFviCR8Nsx0hQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770080121; c=relaxed/simple; bh=l2d5M5deI1WzO0QOi7x/Hlx8HVvtkMiABKSYrRxMGgk=; h=From:Message-ID:Date:MIME-Version:Subject:To:Cc:References: In-Reply-To:Content-Type; b=HY4+XfH2aE5i0I6phn8Y9gWB2kwyx8ss6Lbzc/7v88n5rbLaskqm0enbbqIy+/95dFir7/JIsyGOvG1lrXi8Rw53yUDWxOujO99KAc73AY0jZYGa/tXLuylcGHqtKOjELKy4OYMf6BF72/NMedetUoICR4/k3Qu1uVG070o/pN0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=JvkCGJ+B; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=Hq9mKo9d; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="JvkCGJ+B"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="Hq9mKo9d" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1770080118; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=SjIr2kFnG9dRMyzn5Xr9r8FTYW/SoLc0im+4o9BZWhg=; b=JvkCGJ+BcsRM0dqTsgYh1J4OORhot+wrgWEkRSm4lxEv2oR7aC2r2KfRkiVgegcTeU8ZYw 5b++rWorAvsFom1jMj8xezgeYxpmwFYRChthncOGy8TR7MX3Y3HxUoVdwSCd4aAKMizSrv hoQfRiMqs1MKW14zyG8HxADO4eJCrdo= Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-663-BSlrZ2mSPpGJ5nIaU8rjZw-1; Mon, 02 Feb 2026 19:55:17 -0500 X-MC-Unique: BSlrZ2mSPpGJ5nIaU8rjZw-1 X-Mimecast-MFC-AGG-ID: BSlrZ2mSPpGJ5nIaU8rjZw_1770080117 Received: by mail-qt1-f198.google.com with SMTP id d75a77b69052e-50341fddb89so159183451cf.3 for ; Mon, 02 Feb 2026 16:55:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1770080117; x=1770684917; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:user-agent:mime-version:date:message-id:from:from:to :cc:subject:date:message-id:reply-to; bh=SjIr2kFnG9dRMyzn5Xr9r8FTYW/SoLc0im+4o9BZWhg=; b=Hq9mKo9daIdZ/VPMQD8p5Cjf8gPgBo4oudbbVrtBnYkrvcedDXABdPLd/t9c9jnFfx Cglok7pxC0UdMneFDhIJuFLMasaZk3Erllx8QlChr4mBTdqOhWNv1KBd5URmg5rIz2U7 yjVid3ibCuZktGhnUmgvY4HQCqroqI4xTqfYTIKKQ19Nh1hRnd0Cr66BzWqIOvFhSd82 txFea1eGRfK6aXBT1jbZRwOJssYYXJEhlmVyn9oEpuin2vGdO56HV9s3tvab2sV/n7yv gLc4btIfUqR9DVXjGRvJOKUsAzuYSMmJ17g1LMLj7W+CMpJkia5TfVPp3dE01/uFKB37 B7wA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770080117; x=1770684917; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:user-agent:mime-version:date:message-id:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=SjIr2kFnG9dRMyzn5Xr9r8FTYW/SoLc0im+4o9BZWhg=; b=hKwAognwxQWCPpOqxatzD+vSNHOi7WdeN9ysG1dAnZhpN99+4sJeAWyIIqb2Eejnwz +bfO0ncJTYO0xv9AlaQP7206B3oZ2FvCyafWfRu+D863cae+QWy6BDzrhQtFL/3GolHb ZyyDeA5MYcDzSw+pb1axS/epCYCNh93OwsuzllWNu7cQN/yL5AgkkkEwPqXRTzo9yr0x hRbTVbP5huXyhISmZkkE14SWmyQ8wnhXzAjLeI5RlKkXdknIr+T+peef9C+O12QktcdK o3nqO+7nNifvQXBtUVVhUVraf/+UvPwH9Y1zM6VBZ0tATJuS4uOR7/SbBEpxQ64eduBt QpJw== X-Forwarded-Encrypted: i=1; AJvYcCV+gBk3f20GG1UxdaKaIz/K7HNK2QHwsTcNU8T1H3mZQVvaTnYmq7kTmskezbFSfZtKbDfaGbfhIL7U4OA=@vger.kernel.org X-Gm-Message-State: AOJu0YyMfdJ9Dwj6jI/45kMj0vShZtc9nHXUUAmAlGOQgpUqQYv5r4Ze rS/UPPJdr4h8AF1rBUt2WBJI5QfQmZrEMVas0wg/8+H2jnbgRZCSViuwSGkwgfFijqs1wOn8cdb fXbsEEi8H8f58nGe9A+qOt4sYeh7fuVPw/XMY9l+ds8gPSYqIJ8nHVeEY4In/uWTgHw== X-Gm-Gg: AZuq6aKn0BPwp/hE1oQrv3Iu86e7PmZ4iJwvXjK4ImJtNNbW+iSsIpPUm0dTr77K/3Z ZxGXDyd8mXzp+g6Y6RfnIVoBvA1+5qT8o6dD2CtnqL3fxiXF402pe8fHTgZ/5ytzXA1qkBojy1u GoDgJv/dwu0ghaCEticiWY6X8pNHkEwD87NWu124NJiI6beZPogRpNu5l96iX/TyYhc8sX3kzRR hYQf6E+FCJ4Fko2wXg9cLKBRUd5qjavkzTrenag3j2OWGScZ28KqrkZmu+/VlLuinE3bj308sBk z5DkAUcoawxO1MtcO4dWXv5AnGFipmQx1gW/6mH3TeDyovdRCREopbUl9KfHwkyyDGdCbv3rBzU rVl5rZquPj1MaZPUTcrPNB+8I6KJ582bjzlhwEuYwpLO6g24aYvsL0IhZ X-Received: by 2002:a05:622a:1308:b0:502:a100:4054 with SMTP id d75a77b69052e-505d217d0a4mr175263611cf.23.1770080116687; Mon, 02 Feb 2026 16:55:16 -0800 (PST) X-Received: by 2002:a05:622a:1308:b0:502:a100:4054 with SMTP id d75a77b69052e-505d217d0a4mr175263341cf.23.1770080116324; Mon, 02 Feb 2026 16:55:16 -0800 (PST) Received: from ?IPV6:2601:188:c102:b180:1f8b:71d0:77b1:1f6e? ([2601:188:c102:b180:1f8b:71d0:77b1:1f6e]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-894d3740e62sm125467246d6.26.2026.02.02.16.55.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Feb 2026 16:55:15 -0800 (PST) From: Waiman Long X-Google-Original-From: Waiman Long Message-ID: <3119bafd-5cdc-4f0a-86df-d245a43aef1b@redhat.com> Date: Mon, 2 Feb 2026 19:55:14 -0500 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH/for-next v3 2/3] cgroup/cpuset: Defer housekeeping_update() calls from CPU hotplug to workqueue To: Peter Zijlstra , Waiman Long Cc: Chen Ridong , Tejun Heo , Johannes Weiner , =?UTF-8?Q?Michal_Koutn=C3=BD?= , Ingo Molnar , Juri Lelli , Vincent Guittot , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , Anna-Maria Behnsen , Frederic Weisbecker , Thomas Gleixner , Shuah Khan , cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org References: <20260202201144.1669260-1-longman@redhat.com> <20260202201144.1669260-3-longman@redhat.com> <20260202201844.GJ1395266@noisy.programming.kicks-ass.net> <20260202204806.GL1395266@noisy.programming.kicks-ass.net> Content-Language: en-US In-Reply-To: <20260202204806.GL1395266@noisy.programming.kicks-ass.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2/2/26 3:48 PM, Peter Zijlstra wrote: > On Mon, Feb 02, 2026 at 03:32:03PM -0500, Waiman Long wrote: >> On 2/2/26 3:18 PM, Peter Zijlstra wrote: >>> On Mon, Feb 02, 2026 at 03:11:43PM -0500, Waiman Long wrote: >>> >>>> @@ -1310,14 +1321,34 @@ static bool prstate_housekeeping_conflict(int prstate, struct cpumask *new_cpus) >>>> */ >>>> static void update_isolation_cpumasks(void) >>>> { >>>> - int ret; >>>> + static DECLARE_WORK(isolcpus_work, isolcpus_workfn); >>>> if (!isolated_cpus_updating) >>>> return; >>>> - ret = housekeeping_update(isolated_cpus); >>>> - WARN_ON_ONCE(ret < 0); >>>> + /* >>>> + * This function can be reached either directly from regular cpuset >>>> + * control file write or via CPU hotplug. In the latter case, it is >>>> + * the per-cpu kthread that calls cpuset_handle_hotplug() on behalf >>>> + * of the task that initiates CPU shutdown or bringup. >>>> + * >>>> + * To have better flexibility and prevent the possibility of deadlock >>>> + * when calling from CPU hotplug, we defer the housekeeping_update() >>>> + * call to after the current cpuset critical section has finished. >>>> + * This is done via workqueue. >>>> + */ >>>> + if (current->flags & PF_KTHREAD) { >>> /* Serializes the static isolcpus_workfn. */ >>> lockdep_assert_held(&cpuset_mutex); >> Do we require synchronization between the the queue_work() call and the >> execution of the work function? I thought it is not needed, but I may be >> wrong. > Well, something needs to ensure there aren't two threads trying to use > this one work thing at the same time, no? isolcpus_workfn() does touches the work struct and there can't be more than one thread calling queue_work() with the same work. However it is possible that if isolcpus_workfn() and this code path are completely async, there is a chance that we may miss a call to housekeeping_update(). So I need to take a further look into that. Cheers, Longman