lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTi=i-fgng0Pa2JDSy8RgqRs2mo2vc2CKbx12-=Ri@mail.gmail.com>
Date:	Fri, 25 Feb 2011 02:03:54 -0800
From:	Paul Turner <pjt@...gle.com>
To:	jacob pan <jacob.jun.pan@...ux.intel.com>
Cc:	linux-kernel@...r.kernel.org,
	Bharata B Rao <bharata@...ux.vnet.ibm.com>,
	Dhaval Giani <dhaval@...ux.vnet.ibm.com>,
	Balbir Singh <balbir@...ux.vnet.ibm.com>,
	Vaidyanathan Srinivasan <svaidy@...ux.vnet.ibm.com>,
	Gautham R Shenoy <ego@...ibm.com>,
	Srivatsa Vaddagiri <vatsa@...ibm.com>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Matt Helsley <matthltc@...ibm.com>
Subject: Re: [CFS Bandwidth Control v4 0/7] Introduction

On Thu, Feb 24, 2011 at 4:11 PM, jacob pan
<jacob.jun.pan@...ux.intel.com> wrote:
> On Tue, 15 Feb 2011 19:18:31 -0800
> Paul Turner <pjt@...gle.com> wrote:
>
>> Hi all,
>>
>> Please find attached v4 of CFS bandwidth control; while this rebase
>> against some of the latest SCHED_NORMAL code is new, the features and
>> methodology are fairly mature at this point and have proved both
>> effective and stable for several workloads.
>>
>> As always, all comments/feedback welcome.
>>
>
> Hi Paul,
>
> Your patches provide a very useful but slightly different feature for
> what we need to manage idle time in order to save power. What we
> need is kind of a quota/period in terms of idle time. I have been
> playing with your patches and noticed that when the cgroup cpu usage
> exceeds the quota the effect of throttling is similar to what I have
> been trying to do with freezer subsystem. i.e. freeze and thaw at given
> period and percentage runtime.
> https://lkml.org/lkml/2011/2/15/314
>
> Have you thought about adding such feature (please see detailed
> description in the link above) to your patches?
>

So reading the description it seems like rooting everything in a
'freezer' container and then setting up a quota of

(1 - frozen_percentage)  * nr_cpus * frozen_period * sec_to_usec

on a period of

frozen_period * sec_to_usec

Would provide the same functionality.  Is there other unduplicated
functionality beyond this?

One thing that does seem undesirable about your approach is (as it
seems to be described) threads will not be able to take advantage of
naturally occurring idle cycles and will incur a potential performance
penalty even at use << frozen_percentage.

e.g. From your post

       |  |<-- 90% frozen -     ->|  |                               |  |
____|  |________________x_|  |__________________|  |_____

        |<---- 5 seconds     ---->|


Suppose no threads active until the wake up at x, suppose there is an
accompanying 1 second of work for that thread to do.  That execution
time will be dilated to ~1.5 seconds (as it will span the 0.5 seconds
the freezer will stall for).  But the true usage for this period is
~20% <<< 90%

> Thanks,
>
> Jacob
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ