[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-arm
Subject:    Re: Revision 209887
From:       Alan Cox <alc () cs ! rice ! edu>
Date:       2010-07-20 17:35:56
Message-ID: 4C45DE7C.5080207 () cs ! rice ! edu
[Download RAW message or body]

Mark Tinguely wrote:
> This is a FYI on the pmap_qenter() change in the i386/amd64 - revision 
> 209887.
> PS to last week's email. Sorry I did not keep the message-id consistent.
>
> A similar change in the ARM pmap_kenter_internal() seems to help 
> significantly. Running a port (bash3) compile on a modified GUMSTIX 
> kernel on an emulator, I am getting mid-teen percentages of mapping 
> request that we do not have to do. An example snapshot of the counts:
>
>    2475 kenter()s not needed.
>    11479 enters required.
>    All 11479 old ptes were zero because we aggressively remove 
> dangling allocation.
>
> As the compilation continues, the ratio between kenter()s not needed 
> per kenters() needed goes up.
>
> The numbers above assume a patch for vfs_unbusy_pages() that is the 
> duplicate to the one in bufdone_finish().  In theory the 
> vfs_unbusy_pages() should help keep the number of  unnecessary 
> pmap_qenter() calls down, so the above numbers could only be higher 
> without that patch.
>

Keep in mind that vfs_unbusy_pages() is only used by the NFS client 
code, so it may not affect your particular test anyway.

> I also propose to removed the calls to pmap_wb_page() in pmap_qenter() 
> and pmap_inv_page() in pmap_qremove():
> In pmap_qenter(), pmap_fix_cache() will write back the page mappings 
> and turn off caching if shared.
> If the page was shared when pmap_qremove() is called, the caches will 
> already be turned off, and pmap_kremove() will writeback and 
> invalidate this mapping during the removal process.
>

Alan

_______________________________________________
freebsd-arm@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"
[prev in list] [next in list] [prev in thread] [next in thread]