[mkc2008] Fwd: Mapping - Mapping DB

Jan Bierbaum s3306700 at mail.inf.tu-dresden.de
Mon Apr 6 15:19:59 CEST 2009


Marcus Voelp meinte am 06.04.2009 13:22:
>> Unmapping could take some time because it (potentially) has to remove a
>> complete subtree from the MDB and the corresponding page table entries.
>> But we want short interrupt latency hence unmapping has to be done
>> preemptively. That's when these helping subtree locks come in. So the
>> whole subtree to be unmapped is locked with such a lock. But who exactly
>> will share this lock? All operations including mappings or only
>> concurrent unmaps?
>>   
> Currently, Fiasco implements such a helping lock at the page frame in
> Sigma0 (and when splitting large pages but don't worry). Both map and
> unmap grab this lock to modify the mapping database.

That means in Fiasco the locked "subtree" starts right at the frame and
not at the root node of the respective map/unmap-operation?


>> Mapping on the other hand is supposed to happen atomically. But a map
>> operation not only appends a node in the MDB but also has to change the
>> receiver's page table(s). These are distinct memory operations so atomic
>> CPU-instructions won't help. Or are there any atomic instruction that
>> perform this task? So maps need to use acquire helping locks too, don't
>> they?
>>   
> Atomic does not necessarily mean implemented with atomic CPU
> instructions. Disabling interrupts (possibly in combination with
> non-helping ticket locks) are also means to execute code atomically
> without having to acquire helping locks.

My point is rather that with atomic CPU instructions the maps would
automatically be synchronized with each other and concurrent unmaps. If
maps don't care about the helping locks but instead use their own
locking scheme couldn't that lead to problems? A map could for example
try to insert new nodes in a subtree currently being deleted by a
concurrent unmap.



Regards, Jan.



More information about the mkc2008 mailing list