Matt Thomas comments as;
More systems are getting larger numbers of TLB entries.
...
Invalidate all becomes expensive when your TLBs get very large as does
discarding live entries.
My own conclusion is that invalidating live entries on ASID wrap (=generation
bump), if any, makes little
Matt Thomas has shown long comment lines;
BTW, how do you approach to implement a remote TLB
shootdown?
It depends on the reason for the shootdown. Might as include the
comments of pmap_tlb.c here:
It'd be better organized when parts of this entire comment are
re-ordered, analysis section
On Thu, 6 Jan 2011, Toru Nishimura wrote:
I would propose here to add a new hook in exception return
path for every NetBSD ports. The hook point is at right
after ast() call. The hook is to call TLB ASID bump op
(to write EntryHi with a single mtc0 instruction for MIPS
architecture , for
Eduardo Horvath points an abstruction issue;
I think exposing this implementation detail breaks the abstraction layer
provided by pmap(9) and thus is a bad thing.
True, but it's the matter of pmap(9) specication. TLB is a sort of cache
and NetBSD intentionally omits to define cache
On Fri, 7 Jan 2011, Toru Nishimura wrote:
Eduardo Horvath points an abstruction issue;
I think exposing this implementation detail breaks the abstraction layer
provided by pmap(9) and thus is a bad thing.
True, but it's the matter of pmap(9) specication. TLB is a sort of cache
and
On Fri, 7 Jan 2011, Toru Nishimura wrote:
Eduardo Horvath said;
Exposing this information outside of the MD code base (pmap(9)) breaks
encapsulation.
I never intent to define or extend MI thing.
but adding some generic hook in all the AST code does not look like a good
exercise in
No. The existance of ASIDs along with the hardware implementation is
fundamentally a proprty of the MMU design. Exposing this information
outside of the MD code base (pmap(9)) breaks encapsulation.
In detail, yes. In general, no.
I haven't looked at the ASID issue in detail. But it sounds
On Thu, 6 Jan 2011, der Mouse wrote:
No. The existance of ASIDs along with the hardware implementation is
fundamentally a proprty of the MMU design. Exposing this information
outside of the MD code base (pmap(9)) breaks encapsulation.
In detail, yes. In general, no.
I haven't
There are growing number of CPU architecture which have
ASID to extend TLB VA-PA translation and improve runtime
TLB efficiency. ASID switching is the least cost MMU
operation to make multiple processes run simultaneously.
ASID eliminates the necessity to discard whole TLB context
on each
On Jan 5, 2011, at 6:41 PM, Toru Nishimura wrote:
There are growing number of CPU architecture which have
ASID to extend TLB VA-PA translation and improve runtime
TLB efficiency. ASID switching is the least cost MMU
operation to make multiple processes run simultaneously.
ASID eliminates
Matt Thomas made a comment;
The ASID generational stuff has a downside in that valid
entries will be thrown away. For mips (and booke) I use
a different algorithm which eliminates the overhead of
discarding all the TLB entries when you run out of ASIDs.
It's a good move to pursue efficent
On Jan 5, 2011, at 9:36 PM, Toru Nishimura wrote:
Matt Thomas made a comment;
The ASID generational stuff has a downside in that valid entries will be
thrown away. For mips (and booke) I use
a different algorithm which eliminates the overhead of
discarding all the TLB entries when you
On Jan 5, 2011, at 9:36 PM, Toru Nishimura wrote:
Matt Thomas made a comment;
The ASID generational stuff has a downside in that valid entries will be
thrown away. For mips (and booke) I use
a different algorithm which eliminates the overhead of
discarding all the TLB entries when you
13 matches
Mail list logo
