LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Peter Rival <frival@zk3.dec.com>,
paulus@samba.org, "Martin J. Bligh" <Martin.Bligh@us.ibm.com>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
linux-kernel@vger.kernel.org, jay.estabrook@compaq.com,
rth@twiddle.net
Subject: Re: [PATCH] change name of rep_nop
Date: Tue, 09 Oct 2001 01:03:22 +0100 [thread overview]
Message-ID: <15753.1002585802@redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.33.0110081643230.1064-100000@penguin.transmeta.com>
In-Reply-To: <Pine.LNX.4.33.0110081643230.1064-100000@penguin.transmeta.com>
torvalds@transmeta.com said:
> There's no way we should implement "simon_says".
> There's a difference between stupiud hardware changing memory from
> under us through mapping tricks, and cache coherency in general.
True. Although for simplicity's sake I wasn't talking about the mapping
tricks, this was just for writing/erasing flash chips without doing any
paging - it you're mapping different chips into the same hole you need the
same cache-flush tricks even for read-only chips.
> What you want is the "memory_went_away_from_us()" kind of cache flush,
> which has nothing at all to do with cache coherency. And it should be
> explicitly and clearly named THAT
As you wish. How about:
void memory_went_away_from_us(void);
and
void memory_range_went_away_from_us(unsigned long start, unsigned long len);
Where 'start' is an ioremap cookie.
> and you should not blame the fact that x86 is always 100% cache coherent
> and that the normal cache coherency routines should _never_ be anything
> but a nop.
Indeed. That's eminently sane - it was just the nomenclature and the
documentation which was less so.
> Also note that wbinvd is known to corrupted the caches and lead to
> lockups on certain x86 cores. You need to be a _lot_ more careful than
> just doing it indiscriminately from a driver.
Yeah - but x86 isn't a particularly interesting architecture in this
context. If you can't selectively flush a range, you'll probably find that
you haven't gained enough from being able to do burst reads to offset the
cost of the complete cache flushes.
--
dwmw2
next prev parent reply other threads:[~2001-10-09 0:03 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-05 10:46 Paul Mackerras
2001-10-05 14:37 ` Alan Cox
2001-10-05 18:06 ` Peter Rival
2001-10-05 23:28 ` Paul Mackerras
2001-10-05 23:54 ` Martin J. Bligh
2001-10-06 1:40 ` Paul Mackerras
2001-10-08 19:27 ` Peter Rival
2001-10-08 22:36 ` David Woodhouse
2001-10-08 22:49 ` Alan Cox
2001-10-08 23:06 ` David Woodhouse
2001-10-08 23:42 ` David Woodhouse
2001-10-08 23:46 ` David S. Miller
2001-10-08 23:08 ` David S. Miller
2001-10-08 23:46 ` Linus Torvalds
2001-10-09 0:03 ` David Woodhouse [this message]
2001-10-08 22:46 ` David S. Miller
2001-10-08 23:16 ` Alan Cox
2001-10-08 23:24 ` Dave Jones
2001-10-08 23:33 ` Alan Cox
2001-10-09 5:01 ` George Greer
2001-10-08 23:30 ` David S. Miller
2001-10-09 10:33 ` Benjamin Herrenschmidt
2001-10-09 11:30 ` Keith Owens
2001-10-09 12:13 ` Benjamin Herrenschmidt
2001-10-09 12:15 ` Alan Cox
2001-10-09 8:51 Etienne Lorrain
2001-10-09 11:30 ` Alan Cox
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=15753.1002585802@redhat.com \
--to=dwmw2@infradead.org \
--cc=Martin.Bligh@us.ibm.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=frival@zk3.dec.com \
--cc=jay.estabrook@compaq.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paulus@samba.org \
--cc=rth@twiddle.net \
--cc=torvalds@transmeta.com \
--subject='Re: [PATCH] change name of rep_nop' \
/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
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).