On Thu, May 24, 2007 at 12:43:58AM -0700, Peter Williams wrote: >Peter Williams wrote: >> The relevant code, find_busiest_group() and find_busiest_queue(), has a >> lot of code that is ifdefed by CONFIG_SCHED_MC and CONFIG_SCHED_SMT and, >> as these macros were defined in the kernels I was testing with, I built >> a kernel with these macros undefined and reran my tests. The >> problems/anomalies were not present in 10 consecutive tests on this new >> kernel. Even better on the few occasions that a 3/1 split did occur it >> was quickly corrected to 2/2 and top was reporting approx 49% of CPU for >> all spinners throughout each of the ten tests. >> >> So all that is required now is an analysis of the code inside the ifdefs >> to see why it is causing a problem. > > >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? 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/
