All of 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



  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 [PATCH] change name of rep_nop 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:46             ` David S. Miller
2001-10-08 23:16               ` Alan Cox
2001-10-08 23:24                 ` Dave Jones
2001-10-08 23:30                   ` David S. Miller
2001-10-08 23:33                   ` Alan Cox
2001-10-09  5:01                   ` George Greer
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-08 22:49             ` Alan Cox
2001-10-08 23:06             ` David Woodhouse
2001-10-08 23:08               ` David S. Miller
2001-10-08 23:42               ` David Woodhouse
2001-10-08 23:46                 ` David S. Miller
2001-10-08 23:46             ` Linus Torvalds
2001-10-09  0:03               ` David Woodhouse [this message]
  -- strict thread matches above, loose matches on Subject: below --
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 \
    /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.