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 C9C7114036F for ; Mon, 8 Apr 2024 15:22:59 +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=1712589781; cv=none; b=rmPXJuXDVzlh8fi3dWO7hSSdFd1SkEmIn/GgfZQ9p+VLHbJVPK7tZc15KYu81ScAOFWV1Lk2X0mJKpWObGCdlhqAgS5CWoStdLWlxPQuxJEbBjSHvZOEBVtzbF5fwzAHPxbd6GRHCeBUloZ6G268a/I38pBz0zi5XZI9ifcP/SI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712589781; c=relaxed/simple; bh=OU2tVQvyT4SRuoCW2qCM4+ovjL9o9abprj5AcavWWWE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=cTwjJeMymNFJiiMhK2jJ213RUIy/81qg2NBtJDbXLtKJWGdxBr/uav1B8HtLqrCVzS8PxnPGfWzFY6JaGUeUSxLRGvpvvs7OId8dfBn7DH8sDgqFCVtM7CF67C178SBOe1S/3AYeSoNQTYnRHvdJd3eG3VOt4L3f6TVfGa3sUcw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none 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=ibncLV5x; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none 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="ibncLV5x" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1712589778; 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: in-reply-to:in-reply-to:references:references; bh=uNaLEe1EqaX5cisZeqS+C09rvuUmVecNNaJN/+fnKGc=; b=ibncLV5xqay9XjS7DvkKxu5UWg6bpwjatYfmsK1PAnNDcgYzEuvC+vZJkw0262lrBe8X8K mbPcTWg9apztFK8TGQd92ZYJ2iBUBd7QV6RXq/w6aQVP0KeQffl5GF9tSschbDOWdGl3zq elwmNEy4SrdkkOSciHzHmcf1Hr8qt2w= Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-651-ySSsIh20NbOAMCXmbsZBZQ-1; Mon, 08 Apr 2024 11:22:57 -0400 X-MC-Unique: ySSsIh20NbOAMCXmbsZBZQ-1 Received: by mail-qk1-f199.google.com with SMTP id af79cd13be357-78c4db6bd8dso372136785a.2 for ; Mon, 08 Apr 2024 08:22:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712589777; x=1713194577; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=uNaLEe1EqaX5cisZeqS+C09rvuUmVecNNaJN/+fnKGc=; b=dR1T5edNuegIO3SoWJQ4fWvX9KvcxXnd+Qjst/Cx+U7vjHADSrwc1fsAKKPVZSnVzG 2MSuhomrHNb+lPzOPyRPIevTvdm0BRQthZAxeaULAK3gVmPKcF0IA/FaNQq9Uyy+PAvr ztrWn9IhmfR2RsZvk5YQeBOKGQ3aVv0KJT/utk1XRSX4KxF7e5IjsNqxB4mqrgE9fJoM MEhSuUevo6dZJk/n2xMCLvH4vxYE5o6buW7VgTWNpf4XyCHhfCPPzIC6/XL4tQQ7OIRf 4usoLiAvXzAL/cDKJ9YcUAzsNlHYtzHhzH1roOEECPMzDbaIZKEpuwIp7DMY9nLPQ5VU V0zQ== X-Gm-Message-State: AOJu0YyJvIJPh9TR8zUGS4KmH5EQZRKJBtUoSIlarIj7OZuVaYrduCGw fxeqvmyTZroChdTskV275Le3VKNc9LkTzEB/uOqUsfgGJsBwmbsS70KihgCV8meRcYRCKSgWrcR NjN+lfvPD1jSL8+B6ncKrsWtRu3U+vs0zjUAulxT/0gyGbsCjM5Qf1+lOWQGMaw== X-Received: by 2002:a05:6214:d81:b0:696:8c2f:9a12 with SMTP id e1-20020a0562140d8100b006968c2f9a12mr9180104qve.37.1712589777098; Mon, 08 Apr 2024 08:22:57 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHSJndSw8uJPc8rgUwKsJDwcdZZq27Y+2zqtPiQYmLDnd0ZNc7Lo/hTxepEvEegZZ6PNqLwXw== X-Received: by 2002:a05:6214:d81:b0:696:8c2f:9a12 with SMTP id e1-20020a0562140d8100b006968c2f9a12mr9180088qve.37.1712589776789; Mon, 08 Apr 2024 08:22:56 -0700 (PDT) Received: from vschneid-thinkpadt14sgen2i.remote.csb (213-44-141-166.abo.bbox.fr. [213.44.141.166]) by smtp.gmail.com with ESMTPSA id ev6-20020a0562140a8600b0069aae04b06esm2277699qvb.85.2024.04.08.08.22.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Apr 2024 08:22:55 -0700 (PDT) From: Valentin Schneider To: Waiman Long , Tejun Heo , Zefan Li , Johannes Weiner , Thomas Gleixner , Peter Zijlstra , "Rafael J. Wysocki" , Len Brown , Pavel Machek , Shuah Khan Cc: linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-pm@vger.kernel.org, linux-kselftest@vger.kernel.org, Frederic Weisbecker , "Paul E. McKenney" , Ingo Molnar , Anna-Maria Behnsen , Alex Shi , Vincent Guittot , Michal =?utf-8?Q?Koutn=C3=BD?= , Waiman Long Subject: Re: [PATCH v2 1/2] cgroup/cpuset: Make cpuset hotplug processing synchronous In-Reply-To: <20240404134749.2857852-2-longman@redhat.com> References: <20240404134749.2857852-1-longman@redhat.com> <20240404134749.2857852-2-longman@redhat.com> Date: Mon, 08 Apr 2024 17:22:50 +0200 Message-ID: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On 04/04/24 09:47, Waiman Long wrote: > Since commit 3a5a6d0c2b03("cpuset: don't nest cgroup_mutex inside > get_online_cpus()"), cpuset hotplug was done asynchronously via a work > function. This is to avoid recursive locking of cgroup_mutex. > > Since then, the cgroup locking scheme has changed quite a bit. A > cpuset_mutex was introduced to protect cpuset specific operations. > The cpuset_mutex is then replaced by a cpuset_rwsem. With commit > d74b27d63a8b ("cgroup/cpuset: Change cpuset_rwsem and hotplug lock > order"), cpu_hotplug_lock is acquired before cpuset_rwsem. Later on, > cpuset_rwsem is reverted back to cpuset_mutex. All these locking changes > allow the hotplug code to call into cpuset core directly. > > The following commits were also merged due to the asynchronous nature > of cpuset hotplug processing. > > - commit b22afcdf04c9 ("cpu/hotplug: Cure the cpusets trainwreck") > - commit 50e76632339d ("sched/cpuset/pm: Fix cpuset vs. suspend-resume > bugs") > - commit 28b89b9e6f7b ("cpuset: handle race between CPU hotplug and > cpuset_hotplug_work") > > Clean up all these bandages by making cpuset hotplug > processing synchronous again with the exception that the call to > cgroup_transfer_tasks() to transfer tasks out of an empty cgroup v1 > cpuset, if necessary, will still be done via a work function due to the > existing cgroup_mutex -> cpu_hotplug_lock dependency. It is possible > to reverse that dependency, but that will require updating a number of > different cgroup controllers. This special hotplug code path should be > rarely taken anyway. > > As all the cpuset states will be updated by the end of the hotplug > operation, we can revert most the above commits except commit > 50e76632339d ("sched/cpuset/pm: Fix cpuset vs. suspend-resume bugs") > which is partially reverted. Also removing some cpus_read_lock trylock > attempts in the cpuset partition code as they are no longer necessary > since the cpu_hotplug_lock is now held for the whole duration of the > cpuset hotplug code path. > > Signed-off-by: Waiman Long Tested-by: Valentin Schneider