From: Steffen Klassert <steffen.klassert@secunet.com>
To: Ben Hutchings <ben@decadent.org.uk>
Cc: David Miller <davem@davemloft.net>,
netdev@vger.kernel.org,
Chase Douglas <chase.douglas@canonical.com>,
Arne Nordmark <nordmark@mech.kth.se>
Subject: Re: [PATCH net-next-2.6 2/2] 3c59x: Use fine-grained locks for MII and windowed register access
Date: Thu, 24 Jun 2010 16:00:57 +0200 [thread overview]
Message-ID: <20100624140057.GJ5570@secunet.com> (raw)
In-Reply-To: <1277384239.26161.162.camel@localhost>
On Thu, Jun 24, 2010 at 01:57:19PM +0100, Ben Hutchings wrote:
> >
> > This adds a lot of calls to spin_lock_irqsave/spin_unlock_irqrestore to many
> > places where this is not necessary at all. For example during device probe and
> > device open, window_read/window_write are called multiple times, each time
> > disabling the interrupts. I'd suggest to have unlocked, locked and irqsave
> > versions of window_read/window_write and use them in appropriate places.
>
> So what? These are not speed-critical. The fast-path functions do
> acquire the lock just once.
>
The point is that we should not disable the interrupts if we don't need to
do so. It is not speed critical for the 3c59x driver but disabling the
interrupts should be avoided whenever possible. For example during device
probe and device open we can't race against an interrupt handler because
the device is not yet running.
An example from vortex_probe1() is:
for (i = 0; i < 6; i++)
window_write8(vp, dev->dev_addr[i], 2, i);
which expands to someting like:
for (i = 0; i < 6; i++) {
unsigned long flags;
spin_lock_irqsave(&vp->window_lock, flags);
window_set(vp, window);
iowrite8(dev->dev_addr[i], vp->ioaddr + i);
spin_unlock_irqrestore(&vp->window_lock, flags);
return ret;
}
which is quite odd in a codepath that could simply do:
for (i = 0; i < 6; i++) {
window_set(vp, window);
iowrite8(dev->dev_addr[i], vp->ioaddr + i);
}
>
> This locked section is now very short - 5 or 6 register read/writes and
> no delays. We might even be able to get away without locking here as
> the only software state this accesses is dev->if_port and I don't think
> it can race with anything except SIOCGIFMAP (which seems harmless).
>
Best would be, if we don't need to disable the interrupts on this cpu
at all. But then we probaply need to disable the interupt line with
disable_irq. That's why I suggested to move the timer to thread context.
Steffen
next prev parent reply other threads:[~2010-06-24 13:59 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-23 23:52 [PATCH net-next-2.6 0/2] 3c59x: Locking fixes Ben Hutchings
2010-06-23 23:54 ` [PATCH net-next-2.6 1/2] 3c59x: Specify window explicitly for access to windowed registers Ben Hutchings
2010-06-29 6:20 ` David Miller
2010-06-23 23:55 ` [PATCH net-next-2.6 2/2] 3c59x: Use fine-grained locks for MII and windowed register access Ben Hutchings
2010-06-24 12:05 ` Steffen Klassert
2010-06-24 12:57 ` Ben Hutchings
2010-06-24 14:00 ` Steffen Klassert [this message]
2010-06-25 0:45 ` Ben Hutchings
2010-06-25 8:24 ` Steffen Klassert
2010-06-29 6:18 ` David Miller
2010-06-29 6:39 ` Steffen Klassert
2010-06-30 1:26 ` [PATCHv2 net-next-2.6] " Ben Hutchings
2010-06-30 6:15 ` David Miller
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=20100624140057.GJ5570@secunet.com \
--to=steffen.klassert@secunet.com \
--cc=ben@decadent.org.uk \
--cc=chase.douglas@canonical.com \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=nordmark@mech.kth.se \
/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.