From: Eric Dumazet <dada1@cosmosbay.com>
To: Chris Friesen <cfriesen@nortel.com>
Cc: Ray Lee <ray-lk@madrabbit.org>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: questions on NAPI processing latency and dropped network packets
Date: Mon, 14 Jan 2008 20:33:24 +0100 [thread overview]
Message-ID: <478BB904.3060903@cosmosbay.com> (raw)
In-Reply-To: <478BB722.1020004@nortel.com>
Chris Friesen a écrit :
> Eric Dumazet wrote:
>> Chris Friesen a écrit :
>
>>> Based on profiling and instrumentation it seems like the cost of
>>> sctp_endpoint_lookup_assoc() more than triples, which means that the
>>> amount of time that bottom halves are disabled in that function also
>>> triples.
>>
>> Any idea of the size of sctp hash size you have ?
>> (your dmesg probably includes a message starting with SCTP: Hash
>> tables configured...
>> How many concurrent sctp sockets are handled ?
>
> Our lab is currently rebooting, but I'll try and get this once it's
> back up.
>
>> Maybe sctp_assoc_hashfn() is too weak for your use, and some chains
>> are *really* long.
>
> Based on the profiling information we're spending time in
> sctp_endpoint_lookup_assoc() which doesn't actually use hashes, so I
> can't see how the hash would be related. I'm pretty new to SCTP
> though, so I may be missing something.
Well, it does use hashes :)
hash = sctp_assoc_hashfn(ep->base.bind_addr.port, rport);
head = &sctp_assoc_hashtable[hash];
read_lock(&head->lock);
sctp_for_each_hentry(epb, node, &head->chain) {
/* maybe your machine is traversing here a *really* long
chain */
}
>
> Here's the top results from readprofile, unfortunately these are
> aggregated across both cpus so they don't really show what's going on.
> The key thing is that sctp_endpoint_lookup_assoc() is the most
> expensive kernel routine on this entire system.
>
> 3147 .power4_idle 22.4786
> 1712 .native_idle 20.3810
> 1234 .sctp_endpoint_lookup_assoc 2.1725
> 1212 ._spin_unlock_irqrestore 6.4468
> 778 .do_futex 0.3791
> 447 ._spin_unlock_irq 4.2981
> 313 .fget 1.7784
> 277 .fput 3.8472
> 275 .kfree 0.7473
> 234 .__kmalloc 0.5571
> 131 SystemCall_common 0.3411
> 130 .sctp_assoc_is_match 0.6373
> 123 .lock_sock 0.4155
> 119 .find_vma 0.6919
> 116 .kmem_cache_alloc 0.3580
> 111 .kmem_cache_free 0.3343
> 106 .skb_release_data 0.4907
> 102 .__copy_tofrom_user 0.0724
> 100 .exit_elf_binfmt 1.9231
> 100 .do_select 0.0820
>
>
> Chris
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
next prev parent reply other threads:[~2008-01-14 19:33 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-10 17:24 questions on NAPI processing latency and dropped network packets Chris Friesen
2008-01-10 17:37 ` Kok, Auke
2008-01-10 18:12 ` Chris Friesen
2008-01-10 18:26 ` Kok, Auke
2008-01-10 18:25 ` James Chapman
2008-01-10 21:29 ` Chris Friesen
2008-01-10 18:41 ` Rick Jones
2008-01-10 19:01 ` Kok, Auke
2008-01-11 1:20 ` David Miller
2008-01-11 14:59 ` Chris Friesen
2008-01-11 22:29 ` Herbert Xu
2008-01-12 1:53 ` David Miller
2008-01-14 15:58 ` Chris Friesen
2008-01-15 7:19 ` Jarek Poplawski
2008-01-15 14:47 ` Chris Friesen
2008-01-15 15:17 ` Radoslaw Szkodzinski
2008-01-15 17:14 ` Chris Friesen
2008-01-15 17:23 ` Eric Dumazet
2008-01-15 20:29 ` Jarek Poplawski
2008-01-16 0:17 ` Herbert Xu
2008-01-16 6:58 ` Jarek Poplawski
2008-01-16 20:04 ` Willy Tarreau
2008-01-16 22:42 ` Jarek Poplawski
2008-01-12 5:37 ` Ray Lee
2008-01-14 15:49 ` Chris Friesen
2008-01-14 16:56 ` Eric Dumazet
2008-01-14 19:25 ` Chris Friesen
2008-01-14 19:33 ` Eric Dumazet [this message]
2008-01-14 20:02 ` Chris Friesen
2008-01-15 15:09 ` Vlad Yasevich
2008-01-21 19:53 ` Chris Friesen
2008-01-21 21:11 ` Ben Greear
2008-01-21 23:15 ` Chris Friesen
2008-01-21 23:32 ` Ben Greear
2008-01-21 21:31 ` Eric Dumazet
2008-01-21 23:25 ` Chris Friesen
2008-01-22 5:46 ` Eric Dumazet
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=478BB904.3060903@cosmosbay.com \
--to=dada1@cosmosbay.com \
--cc=cfriesen@nortel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=ray-lk@madrabbit.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.