Lock contention in AIO

[Adrian Chadd]

It's the same pages, right? Is it just the refcounting locking that's
causing it?

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.)


-a


On 21 March 2017 at 09:42, Slawa Olhovchenkov <slw at zxy.spb.ru> 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?
> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"