On Wed, Jan 23, 2002 at 11:56:03AM +1100, Paul Mackerras wrote:
> Andrea Arcangeli writes:
>
> > Let's speak about this later. We should ring a bell as soon as we know
> > what's really faster (invlpg at every kmap or global tlb flush once
> > every 1024 kmaps?).
>
> It would be really good if we could have whatever hooks are necessary
> for each architecture to decide this issue in its own way. On PPC for
you could implement pte_offset_nowait as you prefer (it has to
be implemented in include/asm like pte_offset), so yes, if we implement
nowait, you should be free to choose what's best to do on pcc
automatically while fixing the compilation failures.
at the moment there is either "persistent across schedule" or "atomic
local" (not the optimized "_nowait" suggested by Hugh in replacement of
"_atomic") and most of the time we depend on the requirements of the
caller about nonblocking due spinlocks, or persistence for schedules. So
there's not much to choose, only a few places could use both pte_offset
or pte_offset_atomic (on the long run we could turn those, and the other
_atomic into _nowait ones per Hugh suggestion, that would give you the
"hook").
> example a global tlb flush is really expensive, it would be quicker
> for us to either flush each kmap page individually or to flush the
> range of addresses used for kmaps when we wrap. At the very least I
> would like to have a flush_tlb_kernel_range function which would get
> called at the end of flush_all_zero_pkmaps instead of flush_tlb_all.
that's certainly doable, on x86 it will just default to the
global tlb flush because we can't flush it more efficiently than that.
Andrea
-
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/
This archive was generated by hypermail 2b29 : Wed Jan 23 2002 - 21:01:00 EST