Page MenuHomeFreeBSD

Synchronize access to the allpmaps list.
ClosedPublic

Authored by markj on Jan 2 2019, 6:17 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Apr 4, 7:47 PM
Unknown Object (File)
Mar 7 2024, 11:35 PM
Unknown Object (File)
Dec 23 2023, 11:11 AM
Unknown Object (File)
Dec 23 2023, 12:10 AM
Unknown Object (File)
Sep 7 2023, 7:26 AM
Unknown Object (File)
Aug 22 2023, 12:58 PM
Unknown Object (File)
Aug 10 2023, 7:47 AM
Unknown Object (File)
Jul 26 2023, 11:07 AM
Subscribers

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

Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 21810
Build 21078: arc lint + arc unit

Event Timeline

This revision is now accepted and ready to land.Jan 2 2019, 11:45 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.

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.