From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932417AbdJZSMG convert rfc822-to-8bit (ORCPT ); Thu, 26 Oct 2017 14:12:06 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47660 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932343AbdJZSMD (ORCPT ); Thu, 26 Oct 2017 14:12:03 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 8370B80472 Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=longman@redhat.com Subject: Re: [PATCH v3] cpuset: Enable cpuset controller in default hierarchy To: Tejun Heo Cc: Li Zefan , Johannes Weiner , Jonathan Corbet , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-doc@vger.kernel.org, Mike Galbraith , Christian Brauner , =?UTF-8?Q?St=c3=a9phane_Graber?= , Serge Hallyn References: <1507324230-22996-1-git-send-email-longman@redhat.com> <20171026143908.GD59538@devbig577.frc2.facebook.com> From: Waiman Long Organization: Red Hat Message-ID: <2814be69-8dc1-b2f8-406e-cc4dda289d94@redhat.com> Date: Thu, 26 Oct 2017 14:12:01 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <20171026143908.GD59538@devbig577.frc2.facebook.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Content-Language: en-US X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Thu, 26 Oct 2017 18:12:03 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/26/2017 10:39 AM, Tejun Heo wrote: > Hello, Waiman. > > On Wed, Oct 25, 2017 at 11:50:34AM -0400, Waiman Long wrote: >> Ping! Any comment on this patch? > Sorry about the lack of response. Here are my two thoughts. > > 1. I'm not really sure about the memory part. Mostly because of the > way it's configured and enforced is completely out of step with how > mm behaves in general. I'd like to get more input from mm folks on > this. Yes, I also have doubt about which of the additional features are being actively used. That is why the current patch exposes only the memory_migrate flag in addition to the core *cpus and *mems control files. All the other v1 features are not exposed waiting for further investigation and feedback. One way to get more feedback is to have something that people can play with. Maybe we could somehow tag it as experimental so that we can change the interface later on, when necessary, if you have concern about setting the APIs in stone. > 2. I want to think more about how we expose the effective settings. > Not that anything is wrong with what cpuset does, but more that I > wanna ensure that it's something we can follow in other cases where > we have similar hierarchical property propagation. Currently, the effective setting is exposed via the effective_cpus and effective_mems control files. Unlike other controllers that control resources, cpuset is unique in the sense that it is propagating hierarchical constraints on CPUs and memory nodes down the tree. I understand your desire to have a unified framework that can be applied to most controllers, but I doubt cpuset is a good model in this regard. Cheers, Longman