Re: volanoMark regression with kernel 2.6.26-rc1

[Zhang, Yanmin]

On Fri, 2008-05-09 at 21:22 +0530, Srivatsa Vaddagiri wrote:
> On Thu, May 08, 2008 at 11:41:25AM +0530, Srivatsa Vaddagiri wrote:
> > The other combination that I am interested to know is when:
> > 
> > CONFIG_FAIR_GROUP_SCHED=y and CONFIG_CGROUP_SCHED=y
> > 
> > [i.e cgroup based scheduling rather than uid based scheduling. Former
> > should result in only one group at bootup]
> > 
> > I will also try to get some numbers with this combination.
> 
> I ran with that combination and here are some results:
> 
> 2.6.25 (with CONFIG_USER_SCHED) 
> 
> 	Volanomark perf = 20436.6 (Avg of 10 runs)
> 
> 2.6.26-rc1 + patches in Ingo's tree [1] as of Fri morning IST (abt 8 hrs
> before) (with CONFIG_CGROUP_SCHED)
> 	
> 	Volanomark perf = 21529.6
> 
> i.e CGROUP based grouping in 2.6.26-rc1 gives same (if not somewhat
> better) results as UID-based scheduling in 2.6.25.
> 
> Yamin,
> 	Could you validate this as well? i.e just turn on cgroup-based
> grouping (CONFIG_CGROUP_SCHED) and check the resulting performance with 2625
> you already have (using CONFIG_USER_SCHED).
> 
> 
> A) In 2.6.25, with UID based scheduling,
> 	CPU load = summation of task load
> 
> B) In 2.6.26-rc1, with UID based scheduling,
> 	CPU load = summation of group weights
> 
> C) In 2.6.26-rc1, with CGROUP based scheduling,
> 	CPU load = summation of task weights
I'm confused by these conceptions. Would you like to tell me the exact config options
you want to turn on?

Options in my config file(both 2.6.25 and 2.6.26-rc1):

# CONFIG_CGROUPS is not set
CONFIG_GROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
# CONFIG_RT_GROUP_SCHED is not set
CONFIG_USER_SCHED=y
# CONFIG_CGROUP_SCHED is not set

> 
> 
> This change in definition of cpu load is affecting load balance routines
> (find_busiest_group et al). As a result, threads of volanomark benchmark
> aren't quickly spread across the cpus, resulting in slower performance.
> 
> In case of B), cpu load can be low numbers (100 or 200), while in A or
> C, cpu load are large numbers. I think find_busiest_group() and related 
> routines need to be "educated" to deal with such low numbers ..
> 
> 

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