All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jeff V. Merkey" <jmerkey@vger.timpanogas.org>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Gigabit Performance 2.4.19-preX - Excessive locks, calls, waits
Date: Mon, 4 Mar 2002 10:46:09 -0700	[thread overview]
Message-ID: <20020304104609.C31523@vger.timpanogas.org> (raw)
In-Reply-To: <20020304001223.A29448@vger.timpanogas.org> <E16hu0P-0007yq-00@the-village.bc.nu>
In-Reply-To: <E16hu0P-0007yq-00@the-village.bc.nu>; from alan@lxorguk.ukuu.org.uk on Mon, Mar 04, 2002 at 03:04:00PM +0000

On Mon, Mar 04, 2002 at 03:04:00PM +0000, Alan Cox wrote:
> > provided for review.  Recommend a minumum change of increasing 
> > the sysctl_hot_list_len from 128 to 1024 by default.  I have reviewed 
> 
> Good way to kill low end boxes. It probably wants sizing based on system
> size and load monitoring. 
> 
> > NetWare always created ECB's (Event Control Blocks) at the max size
> > of the network adpapter rather than trying to allocate fragment 
> > elements on the fly the way is being done in Linux with skb's.  
> 
> Thats up to the network adapter. In fact the Linux drivers mostly do 
> keep preloaded with full sized buffers and only copy if the packet size
> is small (and copying 1 or 2 cache lines isnt going to hurt anyone)


There's an increase in latency.  For my application, I have no 
problem keeping around a local patch that corrects this behavior 
if folks don't feel it needs fixing.   From everything I've ever
done in this space, having needless alloc/free calls in a 
performance intensive path that requires low latency like a Lan 
driver is not a good thing.  

I am idle most of the time since I have eliminated all of the 
copy activity by using SCI in the system.  This is why it's 
idle most of the time.  Were I using the IP stack code in Linux
proper, the utilization would be through the roof.  

:-)

Jeff


> 
> >  28044 default_idle                             584.2500
> 
> You spent most of your time asleep 8)
> 
> >   1117 __rdtsc_delay                             34.9062
> 
> Or doing delays
> 
> >    927 eth_type_trans                             4.4567
> 
> And pulling a line into L1 cache

  reply	other threads:[~2002-03-04 17:31 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-04  7:12 Gigabit Performance 2.4.19-preX - Excessive locks, calls, waits Jeff V. Merkey
2002-03-04  8:16 ` Andrew Morton
2002-03-04 15:04 ` Alan Cox
2002-03-04 17:46   ` Jeff V. Merkey [this message]
2002-03-04 18:34     ` Alan Cox
2002-03-04 21:02       ` Jeff V. Merkey
2002-03-04 17:39 ` Martin Josefsson
2002-03-04 18:04   ` Jeff V. Merkey
     [not found] <20020304001223.A29448@vger.timpanogas.org.suse.lists.linux.kernel>
2002-03-04  8:28 ` Andi Kleen
2002-03-04 17:41   ` Jeff V. Merkey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020304104609.C31523@vger.timpanogas.org \
    --to=jmerkey@vger.timpanogas.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.