Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932696Ab1BYSZK (ORCPT ); Fri, 25 Feb 2011 13:25:10 -0500 Received: from mga02.intel.com ([134.134.136.20]:28350 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932097Ab1BYSZI (ORCPT ); Fri, 25 Feb 2011 13:25:08 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.62,226,1297065600"; d="scan'208";a="713331895" Date: Fri, 25 Feb 2011 10:23:19 -0800 From: Jacob Pan To: Paul Menage Cc: Matt Helsley , "Rafael J. Wysocki" , LKML , "Kirill A. Shutemov" , Arjan van de Ven , container cgroup , Li Zefan , akpm@linux-foundation.org, rdunlap@xenotime.net, Cedric Le Goater , Linux PM mailing list Subject: Re: [PATCH 1/1, v9] cgroup/freezer: add per freezer duty ratio control Message-ID: <20110225102319.6c776838@putvin> In-Reply-To: References: <1297807750-28844-1-git-send-email-jacob.jun.pan@linux.intel.com> <1297807750-28844-2-git-send-email-jacob.jun.pan@linux.intel.com> <201102160100.15487.rjw@sisk.pl> <20110215163812.7fa020b5@putvin> <20110216032321.GA14893@count0.beaverton.ibm.com> <20110224154525.1b463723@jacob-laptop> Organization: OTC X-Mailer: Claws Mail 3.7.4 (GTK+ 2.20.1; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1262 Lines: 24 On Fri, 25 Feb 2011 09:53:59 -0800 Paul Menage wrote: > On Thu, Feb 24, 2011 at 3:45 PM, jacob pan > wrote: > > I played with v3 and v4 of the CFS bandwidth patch. When the cpu > > cgroup exceeds its cfs_quota, it does have the same effect as this > > patch in terms of freeze/thaw at given period and allowed runtime. > > But when the cgroup cpu usage is below cfs_quota, it is not > > throttled. Therefore, it cannot reduce wakeups. > > How about a userspace daemon that periodically flips the CPU quota for > the cgroup between zero and the group's runnable level? Wouldn't that > achieve what you need pretty easily without having to introduce > additional complexity and threads into the kernel? I think it should work but with little bit more overhead than doing the same in the kernel. It will also need one periodic timer per cgroup. Two extra timer wake ups for each time slice to run. Thanks for the great suggestion. I will do some experiment with it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/