[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [f-cpu] little feed-back from the libre softawre meeting
On Mon, Jul 15, 2002 at 11:20:39AM +0200, Christophe Avoinne wrote:
>
> > > you use a SW tlb, that is ? so you'd better to avoid having several
> entries
> > > pointed out on the same kernel page because of different VMID. Try to
> > > imagine 8 actives processes, you spoiled 8 entries whereas you can just
> have
> > > one entrie for any processes. If you look at the most of SW TLB they
> have a
> > > bit to to tell if we want to check VMID or bypass. If, unhappily, you
> switch
> > > a new process (that is a new VMID), your running kernel code would be
> > > invalidated because of the VMID. It is stupid.
> >
> > That doesn't make sense. The VMID is part of the primary key for TLB
> > lookups. If you ignore it, the keys are no longer unique - the same
> > virtual address may pointer to several different physical pages.
>
> Nope, without the VMID, one virtual address can point only to a unique
> physical page. The programmer would be an idiot if he/she tries to put a
> different physical page with an active VMID (which interest to do so since
> the purpose of using global page is to see it whatever the virtual address
> space is ?). When not using VMID, it is for sharing the same page (physical
> address) in the same virtual address for all processes without exception :
> virtual and physical kernel pages are the same for all the processes, so
> what is the problem ?
I'm not sure if it will work that way.
> Sorry, but nearly all the SW TLB I saw in most modern CPU has the ability to
> check or not the actual ASID in the entry (usual name, Address Space ID)
> with the current ASID (whenever you switch a process with a different
> address space, you must change the current ASID). When the global bit is
> set, you instruct the TLB entry to go along with since it must be considered
> as a unique valid virtual to physical address mapping whatever the ASID is
> (kernel page must be in this category). When this bit is unset, you instruct
> the TLB entry to validate the translation only if the ASID of TLB entry
> matchs the current ASID (your XOR operation).
Should not be hard to implement. We can drop the `present' bit (it
seems to be superfluous) and add a `global' bit instead. If necessary,
a `negative' page mapping can still be performed by an entry with zero
access rights.
> Ok, now, just imagine that case :
>
> Scheduler Timer (preemptive task-switching) expires, an interrupt is raised
> :
> - enter kernel code (with ASID:A for process A).
> - elect process B with a different ASID:B.
> - switch task contest
> - switch the current ASID:A for ASID:B --> * BANG *
>
> What happens ?
>
> * TLB has no entry for our kernel page (contains the code where we switched
> the current ASID) with VMID:B, we raise an exception, but our exception must
> also run in another kernel page which is not in TLB :/
Without a global bit, the kernel must provide TLB entries with the VMID
of the new task while the task switch is in progress. This can probably
be done step-by-step, that is, only one additional TLB entry is required:
add entry for current code page (ASID:B)
switch to ASID:B
change entries for other kernel pages to ASID:B
remove old code page entry
> It is clear that not only ASID is problematic but even without ASID. If we
> had a HW TLB (that is, we have a full array of valid or invalid page entries
> which TLB can get managed with), there is no problem, since TLB knows where
> to look for the translation (example, IA32 MMU/TLB).
>
> For SW TLB, we have no way to tell it where to look the translation because
> it is our exception which is in charge.
>
> So, your exception need to run without TLB (that is with physical addresses
> rather than virtual addresses).
>
> Solutions :
>
> * TLB has no entry for our kernel page (contains the code where we switched
> the current ASID) with VMID:B, we raise an exception in a physical address
> space.
>
> TLB will have two entries with the same virtual and physical address but
> with VMID:A and VMID:B, what a waste ! (I'm speaking about two pages but it
> could be more : the fact is that you would have much more cache misses
> because of possible excessive discarding entries for kernel pages with
> different VMID).
Depends on the cache.
> * kernel code is always running in physical address space (never using TLB,
> as suggested by Whigee)
That would be a choice for an embedded system but not for a real OS.
> Ok, but what is the point to have supervisor/user bit ?????
I don't remember such a bit in my TLB proposal.
--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu in the body. http://f-cpu.seul.org/