On Tuesday 29 May 2007, Gary Zambrano wrote: > On Mon, 2007-05-28 at 13:55 -0700, Maximilian Engelhardt wrote: > > On Monday 28 May 2007, Thomas Gleixner wrote: > > > On Mon, 2007-05-28 at 19:44 +0200, Maximilian Engelhardt wrote: > > > > > Can you please keep CONFIG_HIGH_RES_TIMERS and CONFIG_NOHZ and try > > > > > the following combinations on the kernel command line: > > > > > > > > > > 1) highres=off nohz=off (should be the same as your working config) > > > > > 2) highres=off > > > > > 3) nohz=off > > > > > > > > I tested this with my 2.6.22-rc3 kernel, here are the results: > > > > > > > > without any special boot parameters: problem does appear > > > > highres=off nohz=off: problem does not appear > > > > highres=off: problem does not appear > > > > nohz=off: problem does appear > > > > > > Is there any other strange behavior of the high res enabled kernel than > > > the b44 problem ? > > > > I didn't notice anything. > > > > > > I additionally built my 2.6.22-rc2-mm1 kernel without High Resolution > > > > Timer, but the high ping problem is still there. > > > > > > Hmm, that's mysterious. Wild guess is that highres exposes the hidden > > > "feature" in a different way than rc2-mm1 does. > > > > I think the bug in 2.6.21/22-rc3 is a different one that the one in > > 2.6.22-rc2-mm1, but that's also only a wild guess :) > > > > I'll explain this a bit: > > In 2.6.21/22-rc3 is the same b44 driver that has been in the stock > > kernels for some time. With this driver and High Resolution Timer turned > > on I get problems using iperf. The problems are that the systems becomes > > really slow and unresponsive. Michael Buesch thought this could be an > > IRQ storm which sounds logical to me. This bug did never happen to me > > before I startet the iperf test. > > Can you please check to see if you notice anything out of the ordinary > using netperf in place of iperf in your high res timer on/off testbed? ok, here are the results, I also had a look at the cpu kernel usage. 'good' means that the kernel responsiveness during the test was as I would expect it and I didn't notice any problems. highres enabled: netperf: 80%sy 15%si (good) iperf: not really messureable (bad, problem described above) highres disabled: netperf: 80%sy 15%si (good) iperf: 5%sy 30%hi 15%si (good) for test tests I did run the following commands: netperf -l 60 192.168.1.1 iperf -c 192.168.1.1 -r -t 60 I also tried to run iperf without any additional arguments (iperf -c 192.168.1.1) on the problematic kernel but the result is the same as the command I wrote above. Maxi
Attachment:
signature.asc
Description: This is a digitally signed message part.
