From: Mike Galbraith on
On Thu, 2010-07-08 at 22:44 +0200, Peter Zijlstra wrote:
> On Thu, 2010-07-08 at 21:40 +0200, Mike Galbraith wrote:
> > > Mike could you re-run your netperf tests that showed the 10% throughput
> > > gain? Hopefully the fixed governor will yield the same result and we can
> > > kill off this ratelimit thing.
> >
> > The gain is (well was last time I checked), but as noted, I'd just call
> > it a misguided optimization and be done with it.
>
> It would still be good to know what your machine does, if you can still
> see a difference there might still be something to look at.

git .today.

marge:..git/linux-2.6 # netperf.sh 30
Starting netserver at port 12865
Starting netserver at hostname 0.0.0.0 port 12865 and family AF_UNSPEC
TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 127.0.0.1 (127.0.0.1) port 0 AF_INET
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec

16384 87380 1 1 30.00 102272.73
16384 87380
TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 127.0.0.1 (127.0.0.1) port 0 AF_INET : cpu bind
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec

16384 87380 1 1 30.00 97638.99
16384 87380

turns ratelimiting off

marge:..git/linux-2.6 # netperf.sh 30
Starting netserver at port 12865
Starting netserver at hostname 0.0.0.0 port 12865 and family AF_UNSPEC
TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 127.0.0.1 (127.0.0.1) port 0 AF_INET
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec

16384 87380 1 1 30.00 92991.02
16384 87380
TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 127.0.0.1 (127.0.0.1) port 0 AF_INET : cpu bind
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec

16384 87380 1 1 30.00 97665.27
16384 87380

btw, if you don't set governor to performance, you can get crud
throughput like below, because the ondemand governor doesn't necessarily
notice that the CPUs really are busy when waking cross-cpu.

marge:..git/linux-2.6 # netperf.sh 10
Starting netserver at port 12865
Starting netserver at hostname 0.0.0.0 port 12865 and family AF_UNSPEC
TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 127.0.0.1 (127.0.0.1) port 0 AF_INET
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec

16384 87380 1 1 10.00 73341.95 <== blech
16384 87380
TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 127.0.0.1 (127.0.0.1) port 0 AF_INET : cpu bind
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec

16384 87380 1 1 10.00 97695.45
16384 87380



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Pavel Machek on
On Thu 2010-07-08 11:06:32, Peter Zijlstra wrote:
> On Wed, 2010-07-07 at 01:45 +0900, Norbert Preining wrote:
>
> > it seems that some of the (?)recent(?) changes have increased the
> > power consumption of my note book considerably.
> >
> > First of all, running powertop with normal programs started, but
> > doing nothing, I am still at 14W while I could go down to 9W before
> > (but the 9W was with dimmed display).
> >
> > In the list of top causes for wakeup I have
> > Top causes for wakeups:
> > 34.2% (185.3) [kernel scheduler] Load balancing tick
> > 23.9% (129.6) [extra timer interrupt]
> > 10.8% ( 58.6) firefox-bin
> > 9.2% ( 49.7) [iwlagn] <interrupt>
> > 7.2% ( 39.1) [kernel core] hrtimer_start (tick_sched_timer)
> > 3.9% ( 20.9) PS/2 keyboard/mouse/touchpad interrupt
> > which show one new thing to me I haven't seen before, the Loa balancing tick.
>

14W vs 9W is very significant -- is some DMA keeping system from
entering C3? rmmod usb?
Pavel

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/