Date: Mon, 08 Oct 2001 15:46:50 -0700 (PDT)
Message-Id: <20011008.154650.48796051.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 
From: "David S. Miller" <davem@redhat.com>
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>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org

   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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/