LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "David S. Miller" <davem@redhat.com>
To: dwmw2@infradead.org
Cc: frival@zk3.dec.com, paulus@samba.org, Martin.Bligh@us.ibm.com,
	alan@lxorguk.ukuu.org.uk, torvalds@transmeta.com,
	linux-kernel@vger.kernel.org, jay.estabrook@compaq.com,
	rth@twiddle.net
Subject: Re: [PATCH] change name of rep_nop
Date: Mon, 08 Oct 2001 15:46:50 -0700 (PDT)	[thread overview]
Message-ID: <20011008.154650.48796051.davem@redhat.com> (raw)
In-Reply-To: <13962.1002580586@redhat.com>
In-Reply-To: <1573466920.1002300846@mbligh.des.sequent.com> <15294.24873.866942.423260@cargo.ozlabs.ibm.com> <13962.1002580586@redhat.com>

   From: David Woodhouse <dwmw2@infradead.org>
   Date: Mon, 08 Oct 2001 23:36:26 +0100

   While we're on the subject of stupidly named routines and x86-isms, I'm 
   having trouble reconciling this text in Documentation/cachetlb.txt:
   
   	1) void flush_cache_all(void)
   
   	        The most severe flush of all.  After this interface runs,
   	        the entire cpu cache is flushed.
   
   ... with this implementation in include/asm-i386/pgtable.h:
   
   	#define flush_cache_all()			do { } while (0)
   
   That really doesn't seem to be doing what it says on the tin.
   
"for the purposes of having the processor maintain cache coherency
 due to a kernel level TLB mapping change"

Yes, I know the text isn't there, but that is the implication.
Add the text, don't add a stupid "simon_says.." interface.

The mtrr stuff, if it really does need the flush, should probably
make it's own macro/inline with a huge comment about it explaining
why the flush is actually needed.

   Some people have asserted, falsely, that it's never sane to want an i386 to
   flush its cache.

"for the purposes of having the processor maintain cache coherency
 due to a kernel level TLB mapping change"

All of these flush_foo interfaces are about cache flushes needed when
address space changes occur.  They are not meant to be a way to deal
with all sorts of other cache details, for those we have the PCI DMA
interfaces, flush_dcache_page etc.

   Even if that were true, it wouldn't really be an excuse for
   the above discrepancy.
   
There is no discrepancy, only missing text in cachetlb.txt, please
add it, but I thought that the location of the routine made it obvious
what context it is meant to operate and be used.

Franks a lot,
David S. Miller
davem@redhat.com

  parent reply	other threads:[~2001-10-08 22:49 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
2001-10-08 22:46       ` David S. Miller [this message]
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=20011008.154650.48796051.davem@redhat.com \
    --to=davem@redhat.com \
    --cc=Martin.Bligh@us.ibm.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=dwmw2@infradead.org \
    --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).