From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tejun Heo Subject: Re: [PATCH cgroup/for-3.11 1/3] cgroup: mark "tasks" cgroup file as insane Date: Fri, 7 Jun 2013 13:32:55 -0700 Message-ID: <20130607203255.GD14781@mtj.dyndns.org> References: <20130604021302.GH29989@mtj.dyndns.org> <20130604111556.GA4963@redhat.com> <20130604201947.GE14916@htj.dyndns.org> <20130606092055.GF30217@redhat.com> <20130606211410.GF5045@htj.dyndns.org> <20130607101220.GE10742@redhat.com> <51B1B6C2.7000304@parallels.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=CPPvTvCRrDrH4zndqLVinyzENrk3NCRYdqkrZcBITy8=; b=fYiqAdzxNy3LW6P9NXwnxTlO09fP5kbo9dsFjQNLXe3Z3K8bC/yPkPl3+NhYMgBFiM Dr2lKzXxA52GUp8lhkgwV/PGW8308fbEUJ5FDXKt0iLGukmKRLaSlR45FysZx5O0lCQj Nhq6RSNdY2y86/VSZv3G/EgyqzQdSHmR1lDCr04WJtxBvcHXKm4BNbX9D3t4SH4FgDf2 xDZqDUOwky+DaXIc+RRH3TAgg/IB4S+cbHJE56XkI5WrEYxMGRFTzwOag+/PSFt7B+cW ioAyzvAsLR02AWVpTuEo0Vnrla5dGlIaUk3p+J2LzKCzwsohyesQs6ihzyiMloha5kNy SSRQ== Content-Disposition: inline In-Reply-To: <51B1B6C2.7000304-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Glauber Costa Cc: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, kay.sievers-tD+1rO4QERM@public.gmane.org, Michal Hocko , lennart-mdGvqq1h2p+GdvJs77BJ7Q@public.gmane.org, Johannes Weiner , cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Vivek Goyal Hello, Glauber. On Fri, Jun 07, 2013 at 02:32:34PM +0400, Glauber Costa wrote: > It seems quite valid for me to split priority threads in a process and > give them a 80 % timeslice guarantee, while leaving only 20 % for > low-prio threads (for instance). > > In general, I don't think that it would hurt to allow separation at > thread level *for the leaves*, specifically at the cpu related controllers. But if you look at the larger picture, it actually is deterimental, because allowing different threads of the same process almost implies that the program binary itself would be involved in interacting with - accessing and tuning - cgroups. Back to sysctl analogy, it's one thing to expose them to base system tools which are tightly coupled with the kernel so that they can configure it, but allowing lay programs to embed sysctl tuning inside their binaries is a completely different thing and something which must not happen. While not strictly designated explicitly, things exposed from the kernel have differing levels of exposedness and we do definitely want to avoid exposing too much implementation details for the sake of both the kernel and userland. Such levels are in some cases determined as the use cases develop. If you ask me, cgroup is a good example of things going horribly wrong. So, yeah, while I agree that per-thread usages could make sense for scheduler related controllers, I'd very much like to avoid that if at all possible. It's not a good road to be on. Thanks. -- tejun