[Barrelfish-users] Unmappin pages, tlb flushing

Simon Gerber simon.gerber at inf.ethz.ch
Thu May 23 11:43:35 CEST 2013


1. We don't have any definitive performance numbers for any of the
options you're outlining in regard to TLB flushing (see
http://www.barrelfish.org/gerber-master-vm.pdf for a detailed
explanation of the current memory management system and section 4.3.5
for some results on TLB flushing strategies). I've been experimenting
with different TLB flushing strategies but haven't got any conclusive
results yet.
Regarding the multi-core safeness: As stated below, we don't currently
replicate page tables across cores for the same domain, so if we
remove a mapping in a page table that is used by multiple cores, we
need to flush the other cores TLBs as well. Also, if we were to
replicate page tables we would have to tell all the cores in a domain
to remove the specified page table entries and every core would then
have to invalidate the respective local TLB entries as well.

2. As you can see from the domain-spanning code (especially in
lib/spawndomain/spawn.c:spawn_span_domain()), we just create a copy of
the root page table capability and give that to the part of the domain
running on the new core. Effectively this shares the whole page table
tree between the cores of a domain.

Hope this helps,
-- Simon

On 23 May 2013 10:34, Hegazi, Abdel Rahman Farag Abdel Hakim
<ahegazi at connect.hku.hk> wrote:
> Hello Folks,
> I have a bit long question regarding the unmapping you do here,
> 1 - Check the function page_mappings_unmap ()  at
> ~/kernel/arch/x86_32/page_mapping_arch.c  and also unmap_capability() in
> paging_generic.c file, I can see that you only do the tlb flushing one it is
> just one page you just do either do_one_tlb_flush(vaddr) if #page ==1 or
> do_full_tlb_flush() if #pages>1 why don't you use the third implemented
> function that unmap a contioneous region, or is this related to the cost of
> doing that as I don't know exactly if you did any benchmark on that
> implementation or not, as I can think about some other workaround but need
> matchmaking to measure it how much expensive it is? and one thing checking
> the code of TLB flushing you just commented that do_full_tlb_flush() still
> very expensive and you said it isn't safe for the many-core .. would you
> please explain that UNSAFE for many core as we just reload the cr3 for that
> specific tlb?
> 2- I wanna ask about the page table, as this point still not that clear are
> you dupllicating it between the cores in the same domain?
> --
> Regards,
> Abdelrahman Hegazi
> PhD student, Computer Science,
> Faculty of Engineering,
> Hong Kong University.
> E-mail : abdo.hegazi at connect.hku.hk
> Mobile : (+852) 53053884
> _______________________________________________
> Barrelfish-users mailing list
> Barrelfish-users at lists.inf.ethz.ch
> https://lists.inf.ethz.ch/mailman/listinfo/barrelfish-users

More information about the Barrelfish-users mailing list