Hi,

quoted text
> > > Vacation.. but now I'm back ;-)

quoted text
> > > Even something simple as: perf top -r 1 (make sure you're root in
> > > order to run with real-time prios) could give a clue as to what is
> > > consuming all your cpu-time.

quoted text
> > > Or did the issue get sorted already?

quoted text
> > Thank you for the hint.

quoted text
> > I am on 2.6.35 now and all seems to be fine again.

quoted text
> Are you 100% sure you compiled it with CONFIG_NO_BOOTMEM enabled?

quoted text
> I did not test 2.6.35 yet but I did not see anything related to this
> bug commited since the discussion so I am very surprised the problem
> disappeared by itself...

quoted text
> Will be on vacation very soon, so not sure I will have time to test 2.6.35
> before leaving.

After a few days of running 2.6.35.2 without problem, I got the same
huge slowness for a few tens of seconds yesterday. Did not have time to
run perf (and the system was almost unresponsive), but I will try to do
so if the problem occurs again. Anyway, even if less frequent than
during the -rcs, and as nothing had been commited to fix it before
final, the problem is still there...

It seems that the problem occurs after some CPU intensive tasks have
been run for some time (ie compiling a kernel) and only on Core i7
machines with NO_BOOTMEM. I am surprised so few people reported it and
that it has not been seen on test machines running CPU/scheduler
benchmark tools.

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