On Mon, May 31, 2010 at 10:33:16AM +0200, Peter Zijlstra wrote:
> On Fri, 2010-04-16 at 15:58 +0200, Peter Zijlstra wrote:
> >
> >
> > Hrmm, my brain seems muddled but I might have another solution, let me
> > ponder this for a bit..
> >
>
> Right, so the thing I was thinking about is taking th
On Wed, 2010-06-02 at 04:22 +0530, Vaidyanathan Srinivasan wrote:
> > If the group were a core group, the total would be much higher and we'd
> > likely end up assigning 1 to each before we'd run out of capacity.
>
> This is a tricky case because we are depending upon the
> DIV_ROUND_CLOSEST to d
* Peter Zijlstra [2010-05-31 10:33:16]:
> On Fri, 2010-04-16 at 15:58 +0200, Peter Zijlstra wrote:
> >
> >
> > Hrmm, my brain seems muddled but I might have another solution, let me
> > ponder this for a bit..
> >
>
> Right, so the thing I was thinking about is taking the group capacity
> int
On Fri, 2010-04-16 at 15:58 +0200, Peter Zijlstra wrote:
>
>
> Hrmm, my brain seems muddled but I might have another solution, let me
> ponder this for a bit..
>
Right, so the thing I was thinking about is taking the group capacity
into account when determining the capacity for a single cpu.
S
In message <1271426308.1674.429.ca...@laptop> you wrote:
> On Wed, 2010-04-14 at 14:28 +1000, Michael Neuling wrote:
>
> > > Right, so I suspect this will indeed break some things.
> > >
> > > We initially allowed 0 capacity for when a cpu is consumed by an RT task
> > > and there simply isn't mu
In message <1271688543.1488.253.ca...@laptop> you wrote:
> On Mon, 2010-04-19 at 07:34 +1000, Michael Neuling wrote:
> > > Are there any numbers available on how much they gain? It might be worth
> > > to stick in real numbers instead of this alleged 15%.
> >
> > I get some gain numbers but obviou
On Mon, 2010-04-19 at 07:34 +1000, Michael Neuling wrote:
> > Are there any numbers available on how much they gain? It might be worth
> > to stick in real numbers instead of this alleged 15%.
>
> I get some gain numbers but obviously the workloads makes a huge
> difference. From a scheduler pers
In message <1271426308.1674.429.ca...@laptop> you wrote:
> On Wed, 2010-04-14 at 14:28 +1000, Michael Neuling wrote:
>
> > > Right, so I suspect this will indeed break some things.
> > >
> > > We initially allowed 0 capacity for when a cpu is consumed by an RT task
> > > and there simply isn't m
On Wed, 2010-04-14 at 14:28 +1000, Michael Neuling wrote:
> > Right, so I suspect this will indeed break some things.
> >
> > We initially allowed 0 capacity for when a cpu is consumed by an RT task
> > and there simply isn't much capacity left, in that case you really want
> > to try and move lo
In message <1271161766.4807.1280.ca...@twins> you wrote:
> On Fri, 2010-04-09 at 16:21 +1000, Michael Neuling wrote:
> > When calculating capacity we use the following calculation:
> >=20
> >capacity =3D DIV_ROUND_CLOSEST(power, SCHED_LOAD_SCALE);
> >=20
> > In SMT2, power will be 1178/2 (p
On Fri, 2010-04-09 at 16:21 +1000, Michael Neuling wrote:
> When calculating capacity we use the following calculation:
>
>capacity = DIV_ROUND_CLOSEST(power, SCHED_LOAD_SCALE);
>
> In SMT2, power will be 1178/2 (provided we are not scaling power with
> freq say) and SCHED_LOAD_SCALE will
When calculating capacity we use the following calculation:
capacity = DIV_ROUND_CLOSEST(power, SCHED_LOAD_SCALE);
In SMT2, power will be 1178/2 (provided we are not scaling power with
freq say) and SCHED_LOAD_SCALE will be 1024, resulting in capacity
being 1.
With SMT4 however, power wil
12 matches
Mail list logo
