netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: "David S. Miller" <davem@davemloft.net>
Cc: Jesse Barnes <jbarnes@engr.sgi.com>,
	Andrew Morton <akpm@osdl.org>,
	Linux Kernel list <linux-kernel@vger.kernel.org>,
	netdev@oss.sgi.com, Jeff Garzik <jgarzik@pobox.com>,
	gnb@sgi.com, akepner@sgi.com
Subject: Re: [PATCH] use mmiowb in tg3.c
Date: Fri, 22 Oct 2004 11:16:45 +1000	[thread overview]
Message-ID: <1098407804.6071.22.camel@gaston> (raw)
In-Reply-To: <20041021164007.4933b10b.davem@davemloft.net>

On Fri, 2004-10-22 at 09:40, David S. Miller wrote:
> On Thu, 21 Oct 2004 16:28:06 -0700
> Jesse Barnes <jbarnes@engr.sgi.com> wrote:
> 
> > This patch originally from Greg Banks.  Some parts of the tg3 driver depend on 
> > PIO writes arriving in order.  This patch ensures that in two key places 
> > using the new mmiowb macro.  This not only prevents bugs (the queues can be 
> > corrupted), but is much faster than ensuring ordering using PIO reads (which 
> > involve a few round trips to the target bus on some platforms).
> 
> Do other PCI systems which post PIO writes also potentially reorder
> them just like this SGI system does?  Just trying to get this situation
> straight in my head.

I think the problem they have is really related to their spinlock, that
is the IO leaking out of the spinlock vs. other CPUs.

On the other hand, as I discussed with Jesse in the past, I'd like to
extend the semantics of mmiowb() to also define full barrier between
cacheable and non-cacheable accesses. That would help fixing a lot of issues
on ppc and ppc64.

Typically, our normal "light" write barrier doesn't reorder between cacheable
and non-cacheable (MMIO) stores, which is why we had to put some heavy sync
barrier in our MMIO writes macros.

By having an mmiowb() that allow to explicitely do this ordering, it would
allow us to relax the barriers in the MMIO macros, and so get back a few
percent of perfs that we lost with the "fix".

I haven't had time to work on that yet though, I need to review with paulus
all the possible race cases, but hopefully, I'll have a patch on top of
Jesse next week or so and will start converting more drivers.

Ben.

  reply	other threads:[~2004-10-22  1:16 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200410211613.19601.jbarnes@engr.sgi.com>
2004-10-21 23:28 ` [PATCH] use mmiowb in tg3.c Jesse Barnes
2004-10-21 23:40   ` David S. Miller
2004-10-22  1:16     ` Benjamin Herrenschmidt [this message]
2004-10-22  1:33       ` akepner
2004-10-22  2:07         ` Benjamin Herrenschmidt
2004-10-22  3:01     ` Jesse Barnes
2004-10-22  4:00       ` Paul Mackerras
2004-10-22 20:51   ` [PATCH] use mmiowb in tg3_poll akepner
2005-05-28 23:12     ` Lennert Buytenhek
2005-05-30 16:30       ` Arthur Kepner
2005-05-31 12:53         ` jamal
2005-05-31 16:45           ` Jesse Barnes

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=1098407804.6071.22.camel@gaston \
    --to=benh@kernel.crashing.org \
    --cc=akepner@sgi.com \
    --cc=akpm@osdl.org \
    --cc=davem@davemloft.net \
    --cc=gnb@sgi.com \
    --cc=jbarnes@engr.sgi.com \
    --cc=jgarzik@pobox.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@oss.sgi.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).