You can try these. Your mileage *will* vary.
https://gitorious.org/~kmm/freebsd/kmm-sandbox/commits/work/svn_release_8_1_0_page_lock
https://gitorious.org/~kmm/freebsd/kmm-sandbox/commits/work/svn_trunk_page_lock
On Tue, Apr 24, 2012 at 10:51 PM, K. Macy wrote:
> It's a bit dated at this point
It's a bit dated at this point. Nonetheless, when gitorious is able to
give something other than 503 to my search queries I'll post it.
On Tue, Apr 24, 2012 at 10:45 PM, Slawa Olhovchenkov wrote:
> On Tue, Apr 24, 2012 at 10:43:08PM +0200, K. Macy wrote:
>
>> No. I developed a patch from Jeffr th
On Tue, Apr 24, 2012 at 10:43:08PM +0200, K. Macy wrote:
> No. I developed a patch from Jeffr that pushed the vm_page_lock array
> down in to the machine dependent code, replacing most of the uses of
> the single vm_page_queue_lock. However, alc doesn't like the design
> and has not proposed an al
No. I developed a patch from Jeffr that pushed the vm_page_lock array
down in to the machine dependent code, replacing most of the uses of
the single vm_page_queue_lock. However, alc doesn't like the design
and has not proposed an alternative.
-Kip
On Tue, Apr 24, 2012 at 10:36 PM, Slawa Olhovche
On Tue, Apr 24, 2012 at 09:27:30PM +0200, K. Macy wrote:
> Known problem. There is an open disagreement about how to improve the
> granularity of locking in pmap.
split locking to process-specific information and global information?
use lock-free lists (i see TAILQ_INSERT_TAIL in pmap_enter)?
so
Known problem. There is an open disagreement about how to improve the
granularity of locking in pmap.
-Kip
On Tue, Apr 24, 2012 at 9:14 PM, Slawa Olhovchenkov wrote:
> I treid make -j 30 build{world,kernel} (latest -CURRENT) on 24-core machine
> and see poor
> scalability of pmap/mtx -- more th
