lkml.org 
[lkml]   [2002]   [Mar]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [Lse-tech] Re: 10.31 second kernel compile
Linus Torvalds writes:

> Which brings us back to the whole reason for the discussion: this is not a
> theoretical argument. Look at the POWER4 numbers, and _shudder_ at the
> expense of cache invalidation.

Go a little easy, the ppc64 port is still young and there are still
lots of places where it can use some serious optimization. This is
one of them.

In principle the expense of invalidating the hash-table entries should
be able to be reduced to at most one store for every time we write to
a PTE in the linux page tables. We currently don't have quite enough
information made available to the architecture code to achieve that.
In particular I think it would help if set_pte could be given the
mm_struct and the virtual address, then set_pte could fairly easily
invalidate the hash-table entry (if any) corresponding to the PTE
being changed. Would you consider a patch along these lines?

Another alternative would be to make flush_tlb_mm doing the
change-the-VSIDs trick and then get the idle task to flush the stale
hash table entries. We would need something like a bitmap showing
which PTEs had corresponding hash-table entries so that we didn't
waste time searching for hash-table entries that weren't there.

Paul.
-
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/

\
 
 \ /
  Last update: 2005-03-22 13:21    [W:0.123 / U:0.820 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site