Hi,

I was trying to understand the rationale behind accessing
page tables without a lock from TLB miss handlers without
much luck. Could anyone point me in the right direction?

The only reason I could come up with is that page_mapping-
_insert() may itself block. Examining pt_mapping_insert()
this really seems to be the case - it calls frame_alloc()
without FRAME_ATOMIC. As a result, if there is not enough
memory, frame_alloc() in page_mapping_insert() will sleep
with the page table lock held until more memory is available.
That would in turn block TLB miss handlers attempting to
access the table with the same lock (in case of the tree-
based page table it is protected by locking the address
space). In other words, until more memory is freed threads
of the affected AS would only be able to access TLB cached
pages without blocking, which is definitely a problem.

The problem is exacerbated in case of a global page hash
table. The hash table uses a single mutex for the entire
system. Therefore, sleeping with the lock held would
effectively deadlock the system (but it uses FRAME_ATOMIC).

Are there any other more fundamental reasons for allowing
tlb miss handlers to access the table without a lock?

In earlier communications, Jakub mentioned:
"This has several reasons, such as consistency with the
behavior on platforms with hardware-walked page tables
and the requirements of our non-identity kernel memory."

I am not sure how non-identity kernel memory (is that
the same as high mem?) pertains to page table locking.

Bugs
----
I am afraid traversing the page tables without proper
locking exposes us to several nasty time-dependent bugs
if page_mapping_find() is not coded with extreme care.
A glance at the hash-based as well as tree-base page
table reveals that we would at a minimum have to insert
a number of memory barriers into the code (check out
ht_mapping_insert() and pt_mapping_insert()). Otherwise,
a TLB miss handler might eg see a new page table level/
node before it is fully initialized (the compiler or cpu
may reorder writes and loads). Or have I forgotten to
consider something?

Thanks.

Adam

_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

Reply via email to