In message <1267541076.25158.60.ca...@laptop> you wrote:
> On Sat, 2010-02-27 at 21:21 +1100, Michael Neuling wrote:
> > In message <11927.1267010...@neuling.org> you wrote:
> > > > > If there's less the group will normally be balanced and we fall out a
nd
> > > > > end up in check_asym_packing().
On Sat, 2010-02-27 at 21:21 +1100, Michael Neuling wrote:
> In message <11927.1267010...@neuling.org> you wrote:
> > > > If there's less the group will normally be balanced and we fall out and
> > > > end up in check_asym_packing().
> > > >
> > > > So what I tried doing with that loop is detect if
In message <11927.1267010...@neuling.org> you wrote:
> > > If there's less the group will normally be balanced and we fall out and
> > > end up in check_asym_packing().
> > >
> > > So what I tried doing with that loop is detect if there's a hole in the
> > > packing before busiest. Now that I thin
In message <11927.1267010...@neuling.org> you wrote:
> > > If there's less the group will normally be balanced and we fall out and
> > > end up in check_asym_packing().
> > >
> > > So what I tried doing with that loop is detect if there's a hole in the
> > > packing before busiest. Now that I thin
> > If there's less the group will normally be balanced and we fall out and
> > end up in check_asym_packing().
> >
> > So what I tried doing with that loop is detect if there's a hole in the
> > packing before busiest. Now that I think about it, what we need to check
> > is if this_cpu (the remov
In message <1266942281.11845.521.ca...@laptop> you wrote:
> On Tue, 2010-02-23 at 17:08 +1100, Michael Neuling wrote:
>
> > I have some comments on the code inline but...
> >
> > So when I run this, I don't get processes pulled down to the lower
> > threads. A simple test case of running 1 CPU
On Tue, 2010-02-23 at 17:24 +0100, Peter Zijlstra wrote:
>
> busiest_cpu = group_first_cpu(sds->busiest);
> if (cpu_rq(this_cpu)->nr_running || this_cpu > busiest_cpu)
> return 0;
Hmm, we could change the bit in find_busiest_group() to:
if (idle == CPU_IDLE &&
On Tue, 2010-02-23 at 17:08 +1100, Michael Neuling wrote:
> I have some comments on the code inline but...
>
> So when I run this, I don't get processes pulled down to the lower
> threads. A simple test case of running 1 CPU intensive process at
> SCHED_OTHER on a machine with 2 way SMT system
In message <24165.1266577...@neuling.org> you wrote:
> In message <1266573672.1806.70.ca...@laptop> you wrote:
> > On Fri, 2010-02-19 at 17:05 +1100, Michael Neuling wrote:
> > > > include/linux/sched.h |2 +-
> > > > kernel/sched_fair.c | 61 +
++
>
In message <1266573672.1806.70.ca...@laptop> you wrote:
> On Fri, 2010-02-19 at 17:05 +1100, Michael Neuling wrote:
> > > include/linux/sched.h |2 +-
> > > kernel/sched_fair.c | 61 +++
++--
> > -
> > > 2 files changed, 58 insertions(+), 5 deletions
On Fri, 2010-02-19 at 17:05 +1100, Michael Neuling wrote:
> > include/linux/sched.h |2 +-
> > kernel/sched_fair.c | 61
> > +--
> -
> > 2 files changed, 58 insertions(+), 5 deletions(-)
> >
> > diff --git a/include/linux/sched.h b/include/lin
> On Thu, 2010-02-18 at 09:20 +1100, Michael Neuling wrote:
> > > Suppose for a moment we have 2 threads (hot-unplugged thread 1 and 3, we
> > > can construct an equivalent but more complex example for 4 threads), and
> > > we have 4 tasks, 3 SCHED_OTHER of equal nice level and 1 SCHED_FIFO, the
>
On Thu, 2010-02-18 at 10:28 -0600, Joel Schopp wrote:
> > There's one fundamental assumption, and one weakness in the
> > implementation.
> >
> I'm going to guess the weakness is that it doesn't adjust the cpu power
> so tasks running in SMT1 mode actually get more than they account for?
No,
Sorry for the slow reply, was on vacation. Mikey seems to have answered
pretty well though.
That is, unless these threads 2 and 3 really are _that_ weak, at which
point one wonders why IBM bothered with the silicon ;-)
Peter,
2 & 3 aren't weaker than 0 & 1 but
The core has dyna
On Thu, 2010-02-18 at 14:17 +0100, Peter Zijlstra wrote:
>
> There's one fundamental assumption, and one weakness in the
> implementation.
>
Aside from bugs and the like.. ;-)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.oz
On Thu, 2010-02-18 at 09:20 +1100, Michael Neuling wrote:
> > Suppose for a moment we have 2 threads (hot-unplugged thread 1 and 3, we
> > can construct an equivalent but more complex example for 4 threads), and
> > we have 4 tasks, 3 SCHED_OTHER of equal nice level and 1 SCHED_FIFO, the
> > SCHED_
> Suppose for a moment we have 2 threads (hot-unplugged thread 1 and 3, we
> can construct an equivalent but more complex example for 4 threads), and
> we have 4 tasks, 3 SCHED_OTHER of equal nice level and 1 SCHED_FIFO, the
> SCHED_FIFO task will consume exactly 50% walltime of whatever cpu it
> e
On Fri, 2010-02-05 at 14:57 -0600, Joel Schopp wrote:
> On Power7 processors running in SMT4 mode with 2, 3, or 4 idle threads
> there is performance benefit to idling the higher numbered threads in
> the core.
>
> This patch implements arch_scale_smt_power to dynamically update smt
> thread po
On Power7 processors running in SMT4 mode with 2, 3, or 4 idle threads
there is performance benefit to idling the higher numbered threads in
the core.
This patch implements arch_scale_smt_power to dynamically update smt
thread power in these idle cases in order to prefer threads 0,1 over
thread
19 matches
Mail list logo
