Thread (7 messages) flat view 7 messages, 3 authors, 2012-08-20
DORMANTno replies

Revision v1 of 3 in this series.

Revisions (3)
  1. v1 [diff vs current]
  2. v1 current
  3. resend [diff vs current]

[PATCH 0/3] New algorithm for ASID allocation and rollover

From: Will Deacon <hidden>
Date: 2012-08-20 12:51:16

Hi Arnd,

Thanks for the interest!

On Sun, Aug 19, 2012 at 04:21:37PM +0100, Arnd Bergmann wrote:
On Wednesday 15 August 2012, Will Deacon wrote:
quoted
After some discussion, it became apparent that tracking the ASIDs
currently active on the cores in the system means that, on rollover, we
can automatically reserve those that are in use without having to stop
the world.
Just a question for my general understanding of how this is done: How do
you know if an ASID is active or not? Do you broadcast flush an address
space completely when the struct mm goes away, or do you keep track of
which CPUs had TLBs in an ASIC when it went away and then flush that ASID
when you reuse it on that CPU?
Ok, I'll address these in turn:

1. We know if an ASID is active or not by updating the per-cpu active_asids
   variable when switching mm.

2. Flushing (TLB invalidation) only happens when all ASIDs are dirty. So
   when a struct mm is freed, its ASID remains `dirty' in the asid_map.
   Eventually, no more ASIDs can be allocated, so the flushing takes place
   then. All v7 CPUs broadcast this operation in hardware. At this point, we
   mark all the active ASIDs as dirty to prevent them being re-allocated to
   different tasks.

I did play with per-ASID TLB-flushing depending on ASID pressure but I
couldn't find any benchmarks that showed an improvement.

Cheers,

Will
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help