Received: by 2002:a17:90a:1609:0:0:0:0 with SMTP id n9csp2420526pja; Thu, 26 Mar 2020 15:04:40 -0700 (PDT) X-Google-Smtp-Source: ADFU+vstfM09qE0H8YcfwoAps65l7LwAH5iRVkQ4tYrrkJbbdPZl9upi2vY16HoSdrE+jX06igMq X-Received: by 2002:a9d:6a12:: with SMTP id g18mr6670911otn.19.1585260280287; Thu, 26 Mar 2020 15:04:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585260280; cv=none; d=google.com; s=arc-20160816; b=Id5gN30NkaE83SiqD5ChrBlL/IKbZ2jCI0k1NpUaYQ8KBIhGwonn0Yg1rIGkzYYnS5 DK1myTWAg4rT0kEfGefvyELKH3yn1Pk0t6hqiJ/7ckDd8+pSKQLUVk+hQoZxnslx5L/0 Q28xMiLZ40dRTasmWlXHQUTmSKe+1RfSeiYTJf4BF4otm0LxP8sYT9DfirvtkHN3eE1X i5WVlzJKSAqPgIi0vZBSIUAUb92VRHXoriLeN3WxTQpeSK/YCrOU/Z2NBBxY4nAHl2KE R7dMwyrethKKryxvb6/AoSFEtI/a91SV6zu25qlgsYcJK6Cwat/J1opMVnb5jJNVkGUe fLew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=CVqQ7MESPq+AdE5FevBfn8AolxVmIzRfASYgM+H4STI=; b=avbMFEag4Ih3MVWkM0JgbkIj2woy3KhlT+CEPtShlrmG09s3o4eV//cFnyVCcPU/WF 905Z/akqxhuUwI0GTp4zzGLSPT8nExlDH/aYiXeTtm+jsBMiYVNHQt9WSs9yn31ataOn EhvlLIK+ZQpda91UrVSdcE7DxZURWgCoNVZpCGPZqABKWP0thikDQNzOfpYu84zuYBGk WO2I7LcGBY4fxkMqs2MJ5ZtsMHTkPiPGcoJRw2uIJ+IsSn+m9d5+nX76kQ7a2I2dUwvE DpbvRkBDjIL+rnukf2Tvd8Zbj3qM6gTU7EcgUnNdS2Dyq5Sv7ikxwoC5ZuOl7A2K9yHs zV5g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=szyVRdKU; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a206si1472998oii.132.2020.03.26.15.04.27; Thu, 26 Mar 2020 15:04:40 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=szyVRdKU; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727696AbgCZWD6 (ORCPT + 99 others); Thu, 26 Mar 2020 18:03:58 -0400 Received: from mail-wm1-f67.google.com ([209.85.128.67]:53281 "EHLO mail-wm1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726954AbgCZWD6 (ORCPT ); Thu, 26 Mar 2020 18:03:58 -0400 Received: by mail-wm1-f67.google.com with SMTP id b12so9045719wmj.3 for ; Thu, 26 Mar 2020 15:03:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CVqQ7MESPq+AdE5FevBfn8AolxVmIzRfASYgM+H4STI=; b=szyVRdKUxChTizOYbqe+xujjj60j68XNY2SNyiTfGDb2FOQdOSEPl8zDMtKzEbkOEZ jtQCP5i4iuVP5zMrvcycKgn+qO0lKj6TLMeJBhnVXT7oeJu21WuKDaUh+y8ixfdNBFQE 6oFyY3Q/46KVNkl3A8NeA+LMUYdpO7Slu4Tee/ERY9zUHc82YMPuRjGkqdBeKwfxRCqI KqUxD+S3Z4nw18kpiJmpbKA3PX2nTDSUVzJgPVy956S23Br/VEIcdC+LK3Daw9ljv9+8 qhXItEAmwk5k03a/QD0NnuHKpqd5PPMt7j1aOKfkpLTyiT23voWFEOtliyOSwkXqS9x8 b3Bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CVqQ7MESPq+AdE5FevBfn8AolxVmIzRfASYgM+H4STI=; b=ZpQa/5Mn4D+wnVjaEu80x31btNKQW4P0qN73ksYR+Zxeg54yg1eT7mjo7REgf2pFmn WLiOPUA/bjQksFlMmLegIzu1wC8AnZnqg6663g0EPErUOoectjFmHtVcuAaAYSZYfkRV ooOSF/VvhMZCfeDLFv9Uq6HC7cYM9tS2z+GwScYZ40sC/bo1djRb8zVFsn9Phj2By1ja d3jXUUwFKOvXkWERH/ziPF/5r96PYn7bFU9N7t+JStN2mNIOtk0GvItqVjnntMVhf/hH 9Zco/3qqLh/0MnNvJ4Ut2jOOTPre5ASm8NqOW+wDn4kd+2rCbxzpQHCcx3Yt21OQbbr+ lC5g== X-Gm-Message-State: ANhLgQ3/Jyq42Z7BB9ocWNtDSfpHz7BDTNODHbKcwFPmZw18AIQF6fXh m+ZCKqBpIV8KosHWgxq1pajC2CgxDZR5eGQJXc2xlg== X-Received: by 2002:adf:b60d:: with SMTP id f13mr12155953wre.12.1585260235721; Thu, 26 Mar 2020 15:03:55 -0700 (PDT) MIME-Version: 1.0 References: <20200326191623.129285-1-joel@joelfernandes.org> <20200326192035.GO162390@mtj.duckdns.org> <20200326194448.GA133524@google.com> <972a5c1b-6721-ac20-cec5-617af67e617d@redhat.com> In-Reply-To: From: Sonny Rao Date: Thu, 26 Mar 2020 15:03:42 -0700 Message-ID: Subject: Re: [PATCH RFC] cpuset: Make cpusets get restored on hotplug To: Waiman Long Cc: Joel Fernandes , Tejun Heo , linux-kernel@vger.kernel.org, Dmitry Shmidt , Amit Pundir , kernel-team@android.com, Jesse Barnes , vpillai@digitalocean.com, Peter Zijlstra , Guenter Roeck , Greg Kerr , cgroups@vger.kernel.org, Johannes Weiner , Li Zefan Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 26, 2020 at 2:47 PM Waiman Long wrote: > > On 3/26/20 4:05 PM, Sonny Rao wrote: > >> I think Tejun is concerned about a change in the default behavior of > >> cpuset v1. > >> > >> There is a special v2 mode for cpuset that is enabled by the mount > >> option "cpuset_v2_mode". This causes the cpuset v1 to adopt some of the > >> v2 behavior. I introduced this v2 mode a while back to address, I think, > >> a similar concern. Could you try that to see if it is able to address > >> your problem? If not, you can make some code adjustment within the > >> framework of the v2 mode. As long as it is an opt-in, I think we are > >> open to further change. > > I am surprised if anyone actually wants this behavior, we (Chrome OS) > > found out about it accidentally, and then found that Android had been > > carrying a patch to fix it. And if it were a desirable behavior then > > why isn't it an option in v2? > > > I am a bit confused. The v2 mode make cpuset v1 behaves more like cpuset > v2. The original v1 behavior has some obvious issue that was fixed in > v2. So what v2 option are you talking about? I was merely pointing out the behavior of the v1 implementation is so undesirable that it wasn't kept at all in v2. IMHO, it's a bug that should be fixed, and I think it's possible to keep the old behavior if all cpus are offlined, but since you've added this option we can use it instead. > > Regards, > Longman >