cvs commit: src/sys/i386/i386 pmap.c
peterjeremy at optushome.com.au
Sun Apr 30 07:18:23 UTC 2006
On Sat, 2006-Apr-29 10:21:11 -0700, Peter Wemm wrote:
>In more detail. There is one PTE per page of virtual address space. It
>is used by the hardware to translate a virtual address access to a
>physical address. One normally stores the corresponding physical
>address in there with various control bits (read/write mode etc) and
>most importantly, the 'valid' (PG_V) bit. This tells the hardware of
>the cpu that the physical address it found is valid.
I'll second Julian's "request" that this comment be embedded in the code.
>Stephan realized that the kernel already allocates one PTE per virtual
>page. Although it normally holds physical addresses plus attributes,
>as long as we don't set PG_V, then there are 31 other bits that we
>could use for data storage.
Intel mention that the top 31 bits are available to the OS if the
bottom bit is zero in the 486 Programmers Reference Manual.
>As long as the virtual addresses are page aligned, we neatly avoid all
>the PG_* mode bits as well. We can avoid locking and atomic ops when
>updating these because they are only accessed under the page queues
>mutex. We can avoid doing pte invalidations (tlb shootdowns) because
>there can never be any tlb entries corresponding to them.
Nice piece of lateral thinking by Stephan and yourself.
More information about the cvs-src