netdev
[Top] [All Lists]

Re: Early SPECWeb99 results on 2.5.33 with TSO on e1000

To: "Martin J. Bligh" <Martin.Bligh@xxxxxxxxxx>
Subject: Re: Early SPECWeb99 results on 2.5.33 with TSO on e1000
From: Dave Hansen <haveblue@xxxxxxxxxx>
Date: Fri, 06 Sep 2002 08:29:01 -0700
Cc: "David S. Miller" <davem@xxxxxxxxxx>, hadi@xxxxxxxxxx, tcw@xxxxxxxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx, Nivedita Singhvi <niv@xxxxxxxxxx>
References: <20020905.204721.49430679.davem@xxxxxxxxxx> <18563262.1031269721@[10.10.2.3]>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020822
Martin J. Bligh wrote:
Just to throw another firework into the fire whilst people are awake, NAPI does not seem to scale to this sort of load, which was disappointing, as we were hoping it would solve some of our interrupt load problems ... seems that half the machine goes
idle, the number of simultaneous connections drop way down, and
everything's blocked on ... something ... not sure what ;-)
Any guesses at why, or ways to debug this?

I thought that I already tried to explain this to you. (although it could have been on one of those too-much-coffee-days :)

Something strange happens to the clients when NAPI is enabled on the Specweb clients. Somehow the start using a lot more CPU. The increased idle time on the server is because the _clients_ are CPU maxed. I have some preliminary oprofile data for the clients, but it appears that this is another case of Specweb code just really sucking.

The real question is why NAPI causes so much more work for the client. I'm not convinced that it is much, much greater, because I believe that I was already at the edge of the cliff with my clients and NAPI just gave them a little shove :). Specweb also takes a while to ramp up (even during the real run), so sometimes it takes a few minutes to see the clients get saturated.
--
Dave Hansen
haveblue@xxxxxxxxxx


<Prev in Thread] Current Thread [Next in Thread>