Page MenuHomeFreeBSD

i386: implement sysctl vm.pmap.kernel_maps.
ClosedPublic

Authored by kib on Sep 21 2019, 6:49 PM.
Tags
None
Referenced Files
F101908484: D21739.id62430.diff
Tue, Nov 5, 11:57 AM
Unknown Object (File)
Mon, Oct 28, 4:03 AM
Unknown Object (File)
Oct 2 2024, 5:01 PM
Unknown Object (File)
Oct 2 2024, 4:38 PM
Unknown Object (File)
Oct 2 2024, 3:28 AM
Unknown Object (File)
Sep 20 2024, 12:16 AM
Unknown Object (File)
Sep 18 2024, 4:30 AM
Unknown Object (File)
Sep 17 2024, 2:28 PM
Subscribers

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

markj added inline comments.
sys/i386/i386/pmap.c
6197 ↗(On Diff #62396)

Is there a reason not to define and set pg_nx = 0 in non-PAE-capable kernels?

6302 ↗(On Diff #62396)

The rounddown2 is not needed here. I used it in the amd64 variant since iteration may be restarted while examining the large map. Upon the restart, we might encounter a new large page, and sva will be misaligned. In this i386 variant there are no restarts, so this situation cannot occur.

This revision is now accepted and ready to land.Sep 22 2019, 4:25 PM
sys/i386/i386/pmap.c
6197 ↗(On Diff #62396)

It is a very minor optimization for non-PAE pmap. Actually, not. pg_nx has to be global, and then its type is not compatible between PAE and non-PAE pmaps, so it should not be touched by non-PAE at all.

Note that PAE and non-PAE pmaps co-exist in the same kernel image.

sys/i386/i386/pmap.c
6197 ↗(On Diff #62396)

Hmm, could we perhaps #define pg_nx 0u in pmap_nopae.h?

6285 ↗(On Diff #62396)

In the amd64 sysctl there is an extra newline before each header, not just the first. I slightly prefer that style, but in any case we should try to be consistent. If you prefer to avoid the extra newlines, we should change amd64 too.

sys/i386/i386/pmap.c
6197 ↗(On Diff #62396)

Perhaps. But this should be a separate change with the global pass over the pmap.c.

6285 ↗(On Diff #62396)

The reason why I removed these newlines is because for i386 start of next herald does not delineate end of the previous run. I would require more work to properly mark the ends, and also I want to mark things like clean/exec/pipe submaps etc. This should be done for amd64 and i386 later.

This revision was automatically updated to reflect the committed changes.