Re: [BUGFIX][PATCH] DO flush icache before set_pte() on ia64.

On Thu, 5 Jul 2007 12:13:09 -0600
Mike Stroyan <mike@xxxxxxxxxxx> wrote:
The L3 cache is involved in the HP-UX defect description because the
earlier HP-UX patch PHKL_33781 added flushing of the instruction cache
when an executable mapping was removed. Linux never added that
unsuccessfull attempt at montecito cache coherency. In the current
linux situation it can execute old cache lines straight from L2 icache.

Hmm... I couldn't understand "why icache includes old lines in a new page."
This happens at
- a file is newly loaded into page-cache.
- only on NFS.
- happens very *often* if the program is unlucky.

So I wrote my understainding as I think.

Now, I think icache should be flushed before set_pte().
This is a patch to try that.

1. remove all lazy_mmu_prot_update()...which is used by only ia64.
2. implements flush_cache_page()/flush_icache_page() for ia64.

Something unsure....
3. mprotect() flushes cache before removing pte. Is this sane ?
I added flush_icache_range() before set_pte() here.

Any comments and advices ?

I am concerned about performance consequences. With the change
from lazy_mmu_prot_update to __flush_icache_page_ia64 you dropped
the code that avoids icache flushes for non-executable pages.

Hmm? I added VM_EXEC check in flush_(d|i)cache_page(). Isn't it enough ?

Section 4.6.2 of David Mosberger and Stephane Eranian's
"ia-64 linux kernel design and implementation" goes into some
detail about the performance penalties avoided by limiting icache
flushes to executable pages and defering flushes until the first
fault for execution.

Have you done any benchmarking to measure the performance
effect of these additional cache flushes? It would be particularly
interesting to measure on large systems with many CPUs. The fc.i
instruction needs to be broadcast to all CPUs in the system.

no benchmarks yet.


The only defect that I see in the current implementation of
lazy_mmu_prot_update() is that it is called too late in some
functions that are already calling it. Are your large changes
attempting to correct other defects? Or are you simplifying
away potentially valuable code because you don't understand it?

I know your *simple* patch in April wasn't included. So I wrote this.
In April thread, commenter's advices was "implement flush_icache_page()" I think.
If you have a better patch, please post.

Thanks,
-Kame




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

Relevant Pages

  • Re: Sysinstall automatic filesystem size generation.
    ... much safer with the cache _enabled_, on most drives except the most ... >>advocates, typically against Linux users with journalled fs, on web ... points, even on consumer-grade hardware. ...
    (freebsd-stable)
  • Re: "Resultcache" effect in 10.2.0.4 ??
    ... OS cache he is talking about to show it is responsible. ... the trace file should point you in the right direction as ...  a) as I said, the files are in cooked filesystems, maybe in Solaris ... execute and time the query ...
    (comp.databases.oracle.server)
  • Re: "Resultcache" effect in 10.2.0.4 ??
    ... OS cache he is talking about to show it is responsible. ... as I said, the files are in cooked filesystems, maybe in Solaris ... Run it once with a trace, log out, log ... execute and time the query ...
    (comp.databases.oracle.server)
  • Re: [00/17] Large Blocksize Support V3
    ... with this form of block aggregation - this is pretty much what is ... linux we can't say how nasty it would be. ... what Linux had for a buffer cache. ... Given that small block sizes give us better storage efficiency, ...
    (Linux-Kernel)
  • Re: Improvements to fsck performance in -current ...?
    ... > conjunction with the performance impact it had on Postgre. ... > The tests don't 100% apply, since he was testing with Linux and XFS, ... I doubt seriously that it is the disk caching which is to be blamed here, ... The cache sized on disks ...
    (freebsd-current)
Loading