On Thu, May 24, 2007 at 04:23:19PM -0700, Peter Williams wrote: > Siddha, Suresh B wrote: > > On Thu, May 24, 2007 at 12:43:58AM -0700, Peter Williams wrote: > > > > > > Further testing indicates that CONFIG_SCHED_MC is not implicated and > > > it's CONFIG_SCHED_SMT that's causing the problem. This rules out the > > > code in find_busiest_group() as it is common to both macros. > > > > > > I think this makes the scheduling domain parameter values the most > > > likely cause of the problem. I'm not very familiar with this code so > > > I've added those who've modified this code in the last year or > > > so to the > > > address of this e-mail. > > > > What platform is this? I remember you mentioned its a 2 cpu box. Is it > > dual core or dual package or one with HT? > > It's a single CPU HT box i.e. 2 virtual CPUs. "cat /proc/cpuinfo" > produces:
Peter, I tried on a similar box and couldn't reproduce this problem with x86_64 2.6.22-rc3 kernel and using defconfig(has SCHED_SMT turned on). I am using top and just the spinners. I don't have gkrellm running, is that required to reproduce the issue? I tried number of times and also in runlevels 3,5(with top running in a xterm incase of runlevel 5). In runlevel 5, occasionally for one refresh screen of top, I see three spinners on one cpu and one spinner on other(with X or someother app also on the cpu with one spinner). But it balances nicely for the immd next refresh of the top screen. I tried with various refresh rates of top too.. Do you see the issue at runlevel 3 too? thanks, suresh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
