From: Vernon Mauery <vernux@us.ibm.com>
To: Andi Kleen <andi@firstfloor.org>
Cc: netdev <netdev@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
rt-users <linux-rt-users@vger.kernel.org>
Subject: Re: High contention on the sk_buff_head.lock
Date: Wed, 18 Mar 2009 14:07:32 -0700 [thread overview]
Message-ID: <49C16294.8050101@us.ibm.com> (raw)
In-Reply-To: <87prge1rhu.fsf@basil.nowhere.org>
Andi Kleen wrote:
> Vernon Mauery <vernux@us.ibm.com> writes:
>> So while this issue really hits -rt kernels hard, it has a real effect on
>> mainline kernels as well. The contention of the spinlocks is amplified
>> when they get turned into rt-mutexes, which causes a double context switch.
>
> The new adaptive spin heuristics that have been discussed some time
> ago didn't help? Unsurprisingly making locks a lot more expensive
> has drawbacks as you discovered.
Yes. Well, while the adaptive spinlocks did great things for the
network throughput last time I tested them, they also didn't quite
give the determinism in other areas. It would be nice to be able to
target a handful of trouble locks with adaptive spinlocks.
Even so, though I saw dramatic throughput increases with adaptive
spinlocks, they would still be bound by this same lock contention
that I am seeing when the locks are true spinlocks.
>> &list->lock#3: 24517307 24643791 0.71 1286.62 56516392.42 34834296 44904018 0.60 164.79 31314786.02
>> -------------
>> &list->lock#3 15596927 [<ffffffff812474da>] dev_queue_xmit+0x2ea/0x468
>
> The real "fix" would be probably to use a multi queue capable NIC
> and a NIC driver that sets up multiple queues for TX (normally they
> only do for RX). Then cores or a set of cores (often the number
> of cores is larger than the number of NIC queues) could avoid this
> problem. Disadvantage: more memory use.
Hmmm. So do either the netxen_nic or bnx2x drivers support multiple
queues? (that is the HW that I have access to right now). And do I
need to do anything to set them up?
> But then again I'm not sure it's worth it if the problem only
> happens in out of tree RT.
The effects of the high contention are not quite so pronounced in the
vanilla kernel, but I think we are still limited by this lock. In the
-rt kernel, it is obvious that the lock contention is causing lots of
trouble.
--Vernon
next prev parent reply other threads:[~2009-03-18 21:07 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-18 17:24 High contention on the sk_buff_head.lock Vernon Mauery
2009-03-18 19:07 ` Eric Dumazet
2009-03-18 20:17 ` Vernon Mauery
2009-03-20 23:29 ` Jarek Poplawski
2009-03-23 8:32 ` Eric Dumazet
2009-03-23 8:32 ` Eric Dumazet
2009-03-23 8:37 ` David Miller
2009-03-23 8:50 ` Jarek Poplawski
2009-04-02 14:13 ` Herbert Xu
2009-04-02 14:15 ` Herbert Xu
2009-03-18 20:54 ` Andi Kleen
2009-03-18 21:03 ` David Miller
2009-03-18 21:10 ` Vernon Mauery
2009-03-18 21:38 ` David Miller
2009-03-18 21:49 ` Vernon Mauery
2009-03-19 1:02 ` David Miller
2009-03-18 21:54 ` Gregory Haskins
2009-03-19 1:03 ` David Miller
2009-03-19 1:13 ` Sven-Thorsten Dietrich
2009-03-19 1:17 ` David Miller
2009-03-19 1:43 ` Sven-Thorsten Dietrich
2009-03-19 1:54 ` David Miller
2009-03-19 5:49 ` Eric Dumazet
2009-03-19 5:49 ` Eric Dumazet
2009-03-19 5:58 ` David Miller
2009-03-19 14:04 ` [PATCH] net: reorder struct Qdisc for better SMP performance Eric Dumazet
2009-03-19 14:04 ` Eric Dumazet
2009-03-20 8:33 ` David Miller
2009-03-19 13:45 ` High contention on the sk_buff_head.lock Andi Kleen
2009-03-19 3:48 ` Gregory Haskins
2009-03-19 5:38 ` David Miller
2009-03-19 12:42 ` Gregory Haskins
2009-03-19 20:52 ` David Miller
2009-03-19 12:50 ` Peter W. Morreale
2009-03-19 7:15 ` Evgeniy Polyakov
2009-03-18 21:07 ` Vernon Mauery [this message]
2009-03-18 21:45 ` Eilon Greenstein
2009-03-18 21:51 ` Vernon Mauery
2009-03-18 21:59 ` Andi Kleen
2009-03-18 22:19 ` Rick Jones
2009-03-19 12:59 ` Peter W. Morreale
2009-03-19 13:36 ` Peter W. Morreale
2009-03-19 13:46 ` Andi Kleen
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=49C16294.8050101@us.ibm.com \
--to=vernux@us.ibm.com \
--cc=andi@firstfloor.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=netdev@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.