Subject: Re: Analysis of kern/6891 (ps output) [Was Re: Semi fix for PR kern/6891]
To: Jason Thorpe <email@example.com>
From: Eduardo E. Horvath <firstname.lastname@example.org>
Date: 01/30/1999 07:38:09
On Fri, 29 Jan 1999, Jason Thorpe wrote:
> [ Moving this to tech-kern, BCC'ing the list it was previously on. --thorpej ]
> On Fri, 29 Jan 1999 09:38:47 -0500
> Chuck Cranor <email@example.com> wrote:
> > i looked at this on the i386 a while back but i haven't had
> > time to figure out how to fix it. the problem on the i386 is that
> > pmap_kenter() adds kernel mappings without bumping up the kernel
> > pmap's pm_stats.resident_count [it can't bump it as-is because
> > it doesn't have a lock on the kernel pmap's simplelock.]
> Why doesn't it just acquire that lock, then? Is it defined in the
> pmap_kenter() API that the kernel pmap will not be locked?
> ...what if a given pmap implementation MUST lock the kernel pmap to
> enter a mapping?
> This actually brings up another problem w/ pmap_kenter() that I've
> been meaning to bring up.
> The big deal with pmap_kenter() is that it's faster than the normal
> pmap_enter() path, because it can make some assumptions... it also
> has the specified feature of not doing PV tracking, which is required
> for uvm_loan() to work (prevents certain mappings from being e.g.
> pmap_page_protect()'d, etc.)
> Unfortunately, the lack of PV-tracking has two problems:
> (1) For hardware mod/ref, if you must traverse the PV list
> to get this information, you may lose mod/ref info!
> For software mod/ref emulation (e.g. Alpha), you have the
> problem of not being able to set those mappings to Fault on
> Read/Fault on Write, and thus you also lose mod/ref info!
> (2) On VAC systems (like the HP 320 and HP 350 and on the MIPS R4000),
> it's necessary to cache-inhibit all mappings if a multiple-mapping
> causes a VAC alias (not likely with PMAP_PREFER(), but can
> still happen). Without these PV entries, we can't cache
> inhibit all mappings, and thus we have a cache coherency problem!
> What I'm thinking about doing on the Alpha and hp300 pmaps is instead
> use a bit to say "entered w/ kenter" in the PV entry, so that the
> desired operations (e.g. pmap_page_protect()) are skipped on those
> mappings, but the info can be tracked for the other needs.
I find the pmap_kenter() interface to be an abomination. In addition to
the above two issues (both of which I find bothersome since I need to
handle them) there is the issue of keeping mappings entered through both
pmap_enter() and pmap_kenter() and the associated code paths consistent.
The one nice thing about pmap_kenter() is that it will allow multiple
pages to be mapped at the same time. This is a feature I would like to be
able to make use of to use large PTEs where appropriate. However, this
feature would be most useful for user mappings where a program or shared
library's text or data segments could be mapped in with a single PTE.
What I would prefer would be to dump pmap_kenter() and instead change
pmap_enter() (and other functions that currently only operate on a single
page) to take a range of pages and possibly a parameter to tell pmap that
these pages will never be multiply mapped.
Eduardo Horvath firstname.lastname@example.org
"I need to find a pithy new quote." -- me