From: James Bottomley <JBottomley@Novell.com>
To: Michael Chan <mchan@broadcom.com>
Cc: 'FUJITA Tomonori' <fujita.tomonori@lab.ntt.co.jp>,
"vapier@gentoo.org" <vapier@gentoo.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-parisc@vger.kernel.org" <linux-parisc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: bnx2 fails to compile on parisc because of missing get_dma_ops()
Date: Thu, 17 Jun 2010 08:36:51 -0500 [thread overview]
Message-ID: <1276781811.7285.4.camel@mulgrave.site> (raw)
In-Reply-To: <C27F8246C663564A84BB7AB3439772421B79CBCA21@IRVEXCHCCR01.corp.ad.broadcom.com>
On Thu, 2010-06-17 at 06:30 -0700, Michael Chan wrote:
> James Bottomley wrote:
>
> > On Thu, 2010-06-17 at 05:54 -0700, Michael Chan wrote:
> > > This prefetch improves performance noticeably when the driver is
> > > handling incoming 64-byte packets at a sustained rate.
> >
> > So why not do it unconditionally? The worst that can happen
> > is that you
> > pull in a stale cache line which will get cleaned in the
> > dma_sync, thus
> > slightly degrading performance on incoherent architectures.
>
> The original patch was an unconditional prefetch. There was
> some discussion that it might not be correct if the DMA wasn't
> sync'ed yet on some archs. If the concensus is that it is ok to
> do so, that would be the simplest solution.
It's definitely not "correct" in that it may pull in stale data. But it
should be harmless in that if it does, the subsequent sync will destroy
the cache line (even if it actually pulled in correct data) and prevent
the actual use of the prefetched data being wrong (or indeed being
prefetched at all).
James
next prev parent reply other threads:[~2010-06-17 13:36 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-17 1:13 bnx2 fails to compile on parisc because of missing get_dma_ops() James Bottomley
2010-06-17 1:16 ` David Miller
2010-06-17 12:13 ` FUJITA Tomonori
2010-06-17 1:17 ` Mike Frysinger
2010-06-17 3:53 ` Michael Chan
2010-06-17 4:00 ` Mike Frysinger
2010-06-17 4:03 ` Paul Mundt
2010-06-17 4:10 ` Michael Chan
2010-06-17 6:24 ` Michael Chan
2010-06-17 12:21 ` FUJITA Tomonori
2010-06-17 14:36 ` David Miller
2010-06-17 14:50 ` FUJITA Tomonori
2010-06-17 15:30 ` Paul Mundt
2010-06-22 6:30 ` FUJITA Tomonori
2010-06-22 17:14 ` Grant Grundler
2010-06-22 17:26 ` James Bottomley
2010-06-23 0:38 ` FUJITA Tomonori
2010-06-17 4:20 ` James Bottomley
2010-06-17 12:13 ` FUJITA Tomonori
2010-06-17 12:54 ` Michael Chan
2010-06-17 13:12 ` James Bottomley
2010-06-17 13:30 ` Michael Chan
2010-06-17 13:36 ` James Bottomley [this message]
2010-06-17 14:05 ` FUJITA Tomonori
2010-06-17 14:42 ` Michael Chan
2010-06-17 14:50 ` FUJITA Tomonori
2010-06-17 15:52 ` David Miller
2010-06-17 12:13 ` FUJITA Tomonori
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=1276781811.7285.4.camel@mulgrave.site \
--to=jbottomley@novell.com \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-parisc@vger.kernel.org \
--cc=mchan@broadcom.com \
--cc=netdev@vger.kernel.org \
--cc=vapier@gentoo.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 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).