On Wed, Apr 12, 2017 at 05:21:02PM -0700, Adrian Chadd wrote: > It's the same pages, right?
Perhaps. > Is it just the refcounting locking that's > causing it? Don't know. > I think the biggest thing here is to figure out how to have pages have > a lifecycle where the refcount can be inc/dec (obviously >1, ie not in > a state where you can dec to 0) via atomics, without grabbing a lock. > That'll make this particular use case muuuuch faster. > > (dfbsd does this.) I can try you patch. > -a > > > On 21 March 2017 at 09:42, Slawa Olhovchenkov <[email protected]> wrote: > > I am see lock contetntion cuased by aio read (same file segment from > > multiple process simultaneous): > > > > 07.74% [26756] lock_delay @ /boot/kernel/kernel > > 92.21% [24671] __mtx_lock_sleep > > 52.14% [12864] vm_page_enqueue > > 100.0% [12864] vm_fault_hold > > 87.71% [11283] vm_fault_quick_hold_pages > > 100.0% [11283] vn_io_fault1 > > 100.0% [11283] vn_io_fault > > 99.88% [11270] aio_process_rw > > 100.0% [11270] aio_daemon > > 100.0% [11270] fork_exit > > 00.12% [13] dofileread > > 100.0% [13] kern_readv > > > > Is this know problem? > > _______________________________________________ > > [email protected] mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "[email protected]" _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
