Re: [PATCHv4 2/2] powerpc: implement arch_scale_smt_power for Power7

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Michael Neuling
Date: Monday, February 22, 2010 - 11:08 pm

In message <24165.1266577276@neuling.org> you wrote:
++
vings */
up))

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 (a POWER6 but enabling
SD_ASYM_PACKING).  The single processes doesn't move to lower threads as
I'd hope.

Also, are you sure you want to put this in generic code?  It seem to be
quite POWER7 specific functionality, so would be logically better in
arch/powerpc.  I guess some other arch *might* need it, but seems
unlikely.  

+--
 resources */
e */
omain */

If we are asymetric packing...



This just seems to be a null pointer check.

From the tracing I've done, this is always true (always NULL) at this
point so we return here.


I'm a bit lost as to what this is for.  Any clues you could provide
would be appreciated. :-)

Is the first cpu in this domain's busiest group before the first cpu in
this group.  If, so pick this as the busiest?

Should this be the other way around if we want to pack the busiest to
the first cpu?  Mark it as the busiest if it's after (not before).  

Is group_first_cpu guaranteed to give us the first physical cpu (ie.
thread 0 in our case) or are these virtualised at this point?

I'm not seeing this hit anyway due to the null pointer check above.


This is pretty clear.  Moving stuff to the new function.


This seems to be the core of the packing logic.

We make sure the busiest_cpu is not past total_nr_running.  If it is we
mark as imbalanced.  Correct?

It seems if a non zero thread/group had a pile of processes running on
it and a lower thread had much less, this wouldn't fire, but I'm
guessing normal load balancing would kick in that case to fix the
imbalance.

Any corrections to my ramblings appreciated :-)

Thanks again,
Mikey

--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[PATCH 0/2] sched: arch_scale_smt_powers, Joel Schopp, (Wed Jan 20, 1:00 pm)
Re: [PATCH 2/2] powerpc: implement arch_scale_smt_power fo ..., Benjamin Herrenschmidt, (Wed Jan 20, 2:33 pm)
[tip:sched/core] sched: Fix the place where group powers a ..., tip-bot for Gautham ..., (Thu Jan 21, 6:54 am)
Re: [PATCH 2/2] powerpc: implement arch_scale_smt_power fo ..., Benjamin Herrenschmidt, (Sat Jan 23, 8:00 pm)
Re: [PATCH 2/2] powerpc: implement arch_scale_smt_power fo ..., Benjamin Herrenschmidt, (Mon Jan 25, 9:23 pm)
[PATCHv2 0/2] sched: arch_scale_smt_powers v2, Joel Schopp, (Tue Jan 26, 4:27 pm)
[PATCHv2 1/2] sched: enable ARCH_POWER, Joel Schopp, (Tue Jan 26, 4:28 pm)
Re: [PATCHv2 2/2] powerpc: implement arch_scale_smt_power ..., Benjamin Herrenschmidt, (Tue Jan 26, 5:52 pm)
[PATCHv3 0/2] sched: arch_scale_smt_powers, Joel Schopp, (Thu Jan 28, 4:20 pm)
[PATCHv3 1/2] sched: enable ARCH_POWER, Joel Schopp, (Thu Jan 28, 4:20 pm)
Re: [PATCHv3 2/2] powerpc: implement arch_scale_smt_power ..., Benjamin Herrenschmidt, (Thu Jan 28, 6:23 pm)
Re: [PATCHv2 2/2] powerpc: implement arch_scale_smt_power ..., Benjamin Herrenschmidt, (Thu Jan 28, 6:23 pm)
[PATCHv4 0/2] sched: arch_scale_smt_powers, Joel Schopp, (Fri Feb 5, 1:57 pm)
[PATCHv4 1/2] sched: enable ARCH_POWER, Joel Schopp, (Fri Feb 5, 1:57 pm)
Re: [PATCHv4 2/2] powerpc: implement arch_scale_smt_power ..., Michael Neuling, (Thu Feb 18, 11:05 pm)
Re: [PATCHv4 2/2] powerpc: implement arch_scale_smt_power ..., Michael Neuling, (Mon Feb 22, 11:08 pm)
Re: [PATCHv4 2/2] powerpc: implement arch_scale_smt_power ..., Michael Neuling, (Tue Feb 23, 11:07 pm)