On Fri, Mar 04, 2005 at 02:17:11AM +0000, Charles M. Hannum wrote:
> On Friday 04 March 2005 01:28, Chuck Silvers wrote:
> >  34.52    370.95   370.95   709745     0.52     0.52  genfs_putpages
> >   5.51    695.74    59.24 529689671     0.00     0.00  pmap_clear_attrs
> >   2.17    805.80    23.33 532201987     0.00     0.00  pmap_tlb_shootnow
> 
> I think it's pretty obvious here that genfs_putpages() is doing more work than 
> necessary.  In particular, I have trouble imagining why it needs to call 
> pmap_clear_{modify,referenced}() that many times.

well, it's obvious that genfs_putpages() is doing a lot of work, but
unfortunately that work is necessary given the rest of the VM/pmap design.
the clean/dirty status of a page is only really known to the pmap,
thus we call pmap_clear_modify() to retrieve (and clear) the dirty state.
in most of our pmap implementations, the clean/dirty state is actually
maintained in such a way that we have to consult the MMU hardware to know
for sure if a page is dirty (or for hardware-page-table systems,
the physical memory that the MMU hardware can modify without
software intervention).

to avoid the overhead of the current scheme for finding dirty pages, we'll
need to change the pmap implementations so that the page clean/dirty state
is maintained in software instead of (or as well as) in hardware, and then
change the VM/pmap interface so that that the VM code can quickly find the
dirty pages for a given uvm_object.

-Chuck