From: Greg Banks <gnb@sgi.com>
To: Jesse Barnes <jbarnes@engr.sgi.com>
Cc: akpm@osdl.org, linux-kernel@vger.kernel.org, jeremy@sgi.com,
John Partridge <johnip@sgi.com>,
"David S. Miller" <davem@redhat.com>,
Linux Network Development List <netdev@oss.sgi.com>
Subject: Re: [PATCH] I/O space write barrier
Date: Wed, 29 Sep 2004 20:36:46 +1000 [thread overview]
Message-ID: <20040929103646.GA4682@sgi.com> (raw)
In-Reply-To: <200409271103.39913.jbarnes@engr.sgi.com>
G'day,
On Mon, Sep 27, 2004 at 11:03:39AM -0700, Jesse Barnes wrote:
> On some platforms (e.g. SGI Challenge, Origin, and Altix machines), writes to
> I/O space aren't ordered coming from different CPUs. For the most part, this
> isn't a problem since drivers generally spinlock around code that does writeX
> calls, but if the last operation a driver does before it releases a lock is a
> write and some other CPU takes the lock and immediately does a write, it's
> possible the second CPU's write could arrive before the first's.
>
> This patch adds a mmiowb() call to deal with this sort of situation, and
> adds some documentation describing I/O ordering issues to deviceiobook.tmpl.
> The idea is to mirror the regular, cacheable memory barrier operation, wmb.
>[...]
> Patches to use this new primitive in various drivers will come separately,
> probably via the SCSI tree.
Ok, here's a patch for the tg3 network driver to use mmiowb(). Tests
over the last couple of days has shown that it solves the oopses in
tg3_tx() that I reported and attempted to patch some time ago:
http://marc.theaimsgroup.com/?l=linux-netdev&m=108538612421774&w=2
The CPU usage of the mmiowb() approach is also significantly better
than doing PCI reads to flush the writes (by setting the existing
TG3_FLAG_MBOX_WRITE_REORDER flag). In an artificial CPU-constrained
test on a ProPack kernel, the same amount of CPU work for the REORDER
solution pushes 85.1 MB/s over 2 NICs compared to 146.5 MB/s for the
mmiowb() solution.
--- linux.orig/drivers/net/tg3.c 2004-09-22 17:20:45.%N +1000
+++ linux/drivers/net/tg3.c 2004-09-29 19:45:16.%N +1000
@@ -44,6 +44,19 @@
#include <asm/pbm.h>
#endif
+#ifndef mmiowb
+/*
+ * mmiowb() is a memory-mapped I/O write boundary, useful for
+ * preserving send ring update ordering between multiple CPUs
+ * Define it if it doesn't exist.
+ */
+#ifdef CONFIG_IA64_SGI_SN2
+#define mmiowb() sn_mmiob()
+#else
+#define mmiowb()
+#endif
+#endif
+
#if defined(CONFIG_VLAN_8021Q) || defined(CONFIG_VLAN_8021Q_MODULE)
#define TG3_VLAN_TAG_USED 1
#else
@@ -2725,6 +2738,7 @@ next_pkt_nopost:
tw32_rx_mbox(MAILBOX_RCV_JUMBO_PROD_IDX + TG3_64BIT_REG_LOW,
sw_idx);
}
+ mmiowb();
return received;
}
@@ -3172,6 +3186,7 @@ static int tg3_start_xmit(struct sk_buff
netif_stop_queue(dev);
out_unlock:
+ mmiowb();
spin_unlock_irqrestore(&tp->tx_lock, flags);
dev->trans_start = jiffies;
Greg.
--
Greg Banks, R&D Software Engineer, SGI Australian Software Group.
I don't speak for SGI.
next prev parent reply other threads:[~2004-09-29 10:33 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-27 18:03 [PATCH] I/O space write barrier Jesse Barnes
2004-09-29 10:36 ` Greg Banks [this message]
2004-09-29 20:35 ` David S. Miller
2004-09-29 20:43 ` Jesse Barnes
2004-09-29 20:50 ` David S. Miller
2004-09-30 2:23 ` Greg Banks
2004-09-29 22:55 ` Jesse Barnes
2004-09-30 7:15 ` Jeremy Higdon
2004-09-30 21:21 ` Guennadi Liakhovetski
2004-10-16 0:38 ` Jeremy Higdon
2004-10-16 3:20 ` Matthew Wilcox
2004-10-16 3:31 ` Jeremy Higdon
-- strict thread matches above, loose matches on Subject: below --
2004-10-21 23:13 Jesse Barnes
2004-10-21 23:13 ` Jesse Barnes
2004-10-22 1:01 ` Grant Grundler
2004-10-22 1:01 ` Grant Grundler
2004-10-22 3:05 ` Jesse Barnes
2004-10-22 3:05 ` Jesse Barnes
2004-10-22 4:26 ` Greg Banks
2004-10-22 4:26 ` Greg Banks
2004-10-22 15:26 ` Grant Grundler
2004-10-22 15:26 ` Grant Grundler
2004-10-05 22:38 Jesse Barnes
2004-10-04 20:39 Albert Cahalan
2004-10-04 21:20 ` Jesse Barnes
2004-10-05 0:32 ` Albert Cahalan
2004-10-05 1:22 ` Benjamin Herrenschmidt
2004-10-05 2:26 ` Jesse Barnes
2004-10-05 3:04 ` Benjamin Herrenschmidt
2004-10-05 15:33 ` Jesse Barnes
2004-10-05 22:41 ` Benjamin Herrenschmidt
2004-10-05 23:09 ` Jesse Barnes
2004-10-05 23:57 ` Roland Dreier
2004-10-06 1:45 ` Benjamin Herrenschmidt
2004-10-05 2:33 ` Jesse Barnes
2004-09-23 18:48 Jesse Barnes
2004-09-23 19:03 ` James Bottomley
2004-09-23 19:07 ` Jesse Barnes
2004-09-23 19:27 ` James Bottomley
2004-09-23 19:41 ` Jesse Barnes
2004-09-23 19:57 ` Jeremy Higdon
2004-09-23 22:22 ` Jeremy Higdon
2004-09-23 23:36 ` James Bottomley
2004-09-24 5:03 ` Jeremy Higdon
2004-09-23 19:55 ` Jeremy Higdon
2004-09-23 20:09 ` Jesse Barnes
2004-09-27 0:45 ` Benjamin Herrenschmidt
2004-09-27 15:41 ` Jesse Barnes
2004-09-22 15: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=20040929103646.GA4682@sgi.com \
--to=gnb@sgi.com \
--cc=akpm@osdl.org \
--cc=davem@redhat.com \
--cc=jbarnes@engr.sgi.com \
--cc=jeremy@sgi.com \
--cc=johnip@sgi.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 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.