Page MenuHomeFreeBSD

Synchronize access to the allpmaps list.
ClosedPublic

Authored by markj on Wed, Jan 2, 6:17 PM.

Details

Summary

In the long term we will want to get rid of allpmaps entirely, but this
change is needed until that happens.

Diff Detail

Repository
rS FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

markj created this revision.Wed, Jan 2, 6:17 PM
jhb accepted this revision.Wed, Jan 2, 11:45 PM
This revision is now accepted and ready to land.Wed, Jan 2, 11:45 PM
kib added a comment.Wed, Jan 2, 11:49 PM

I must admit that the use of allpmaps in riscv pmap is somewhat strange. Can we preallocate kernel l1 tables and do not touch them later at all, only copying the kernel part into each new user pmap ?

Regardless of that, why is pmap_distribute_l1() is called from pmap_unwire_l3() ? I do not think that we ever shrink the kernel page tables, this cannot work I believe.

markj added a comment.Thu, Jan 3, 12:01 AM
In D18721#399440, @kib wrote:

I must admit that the use of allpmaps in riscv pmap is somewhat strange. Can we preallocate kernel l1 tables and do not touch them later at all, only copying the kernel part into each new user pmap ?

I think so. I had this approach in mind but didn't implement it yet.

Regardless of that, why is pmap_distribute_l1() is called from pmap_unwire_l3() ? I do not think that we ever shrink the kernel page tables, this cannot work I believe.

One reason to avoid this is because page allocation may fail and we can't tolerate that; pmap_enter() simply panics in that case. Is there another reason?

This revision was automatically updated to reflect the committed changes.