From: Stephen Hemminger <shemminger@osdl•org>
To: "Eric Lemoine" <eric.lemoine@gmail•com>
Cc: "Benjamin Herrenschmidt" <benh@kernel•crashing.org>,
"David S. Miller" <davem@davemloft•net>,
netdev@vger•kernel.org
Subject: Re: [sungem] proposal for a new locking strategy
Date: Mon, 6 Nov 2006 13:49:41 -0800 [thread overview]
Message-ID: <20061106134941.09a7d9bb@freekitty> (raw)
In-Reply-To: <5cac192f0611061310o7b4d267eg37fef6a0cb81bd61@mail.gmail.com>
O
> > > > But the spin is still there, just more complex..
> > > > In qdisc_restart() processing of NETDEV_TX_LOCKED causes:
> > > > spin_lock(dev->xmit_lock)
> > > >
> > > > q->requeue()
> > > > netif_schedule(dev);
> > > >
> > > > SOFTIRQ:
> > > > net_tx_action()
> > > > qdisc_run() --> qdisc_restart()
> > > >
> > > > So instead of spinning in tight loop, you end up with a longer code
> > > > path.
> > >
> > > Stephen, sorry for insisting a bit but I'm failing to see how B is
> > > different from C in that respect. With method B, in qdisc_restart(),
> > > if netif_tx_trylock() fails to acquire the lock then we also
> > > requeue(), etc. Same long code path in case of contention.
> > >
> >
> > Method C LLTX causes repeated softirq's which will be slower since the loop
> > requires more instructions than a simple spin loop (Method B).
>
> What I'm saying above is that Method B also causes repeated tx
> softirqs in case of contention on netif_tx_lock. The code path is :
> netif_tx_trylock() fails -> requeue() -> netif_schedule() ->
> raise_softirq(NET_TX_SOFTIRQ). Am I missing anything?
>
Never mind, you right. I think the netif_tx_trylock() there is a bad
idea because of the long route as shown. Trylock's are usually bad SMP
design anyway. Not sure if it would be possible to change the locking
in qdisc_restart() without causing collateral damage in network drivers.
--
Stephen Hemminger <shemminger@osdl•org>
prev parent reply other threads:[~2006-11-06 21:49 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-05 13:00 [sungem] proposal for a new locking strategy Eric Lemoine
2006-11-05 13:05 ` Benjamin Herrenschmidt
2006-11-05 13:17 ` Eric Lemoine
2006-11-05 17:02 ` Stephen Hemminger
2006-11-05 17:28 ` Eric Lemoine
2006-11-05 17:41 ` Stephen Hemminger
2006-11-05 17:52 ` Eric Lemoine
2006-11-05 18:49 ` Stephen Hemminger
2006-11-05 20:11 ` Eric Lemoine
2006-11-06 17:55 ` Stephen Hemminger
2006-11-06 20:55 ` Eric Lemoine
2006-11-06 20:57 ` Stephen Hemminger
2006-11-06 21:10 ` Eric Lemoine
2006-11-06 21:49 ` Stephen Hemminger [this message]
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=20061106134941.09a7d9bb@freekitty \
--to=shemminger@osdl$(echo .)org \
--cc=benh@kernel$(echo .)crashing.org \
--cc=davem@davemloft$(echo .)net \
--cc=eric.lemoine@gmail$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox