Toru, I'm forwarding your email to the list, I think you missed the "reply-all" button ;)
-------- Original Message -------- Subject: Re: [LM32] ASID support for DTLB Date: Thu, 5 Dec 2013 22:55:45 +0900 From: Toru Nishimura <tslee...@gmail.com> To: Yann Sionneau <y...@minet.net> Hi, all, My name is Toru Nishimura who is interesting in LM32 TLB design. I emphasised that ASID is the essential thing to run TLB effient. The point is that ASID is the technique for "TLB virtualization." 8 bit ASID can make 256 different TLB to run in parallel, for example. Here goes my comment about OS runtime algorithm. The following picked my eyebow. ---- When you run out of ASID (you assigned all of them to different PIDs), then you need to unassign one and assign it to another process (the next one which will run on the CPU). But then, you need to flush the TLB from its entries belonging to the process who used to own the ASID. ---- It's known that "generation number scheme" can run best. Let's say we have two global variables to manage ASID; int asid_nextavail; int asid_generation; 1. Every new process is born with no ASID assigned. When it gets the very first CPU time slot, it gets the fresh value which is maintained by asid_nextavail. The variable gets bumped in that case. 2. Whenever ASID is about to wrap beyond the upper limit, say 255, the entire TLB gets flushed. The next available ASID to assign is the lower bound, say 1 for example. Generation number gets bumped at the same time. 3. Context switch is nothing another than to switch current ASID value. 4. When the newly chosen process takes the CPU, OS sets the ASID of the process to CPU. Before doing so, OS checks whether the process'es generation number is identical to the global variable asid_generation. If found different, i.e., the process'es gen number is behind asid_generation, OS reassigns a fresh ASID for the process, then proceed to set the ASID to CPU. If they are identical, OS simplely uses the value which the process'es had. Simple, isn't it? ASID is essential because UNIX-like OS makes every program have the very same memory layout. The entry points are the same, stack is laid at the same range. Without ASID, context switch mandates to flush the entire TLB. This brings the hopelessly poor runtime due to the very same reason of VIVT cache. Toru Nishimura / IND operation / ALKYL Technology.
_______________________________________________ Devel mailing list Devel@lists.milkymist.org https://ssl.serverraum.org/lists/listinfo/devel