Change Details

About 11 minutes of poudriere -s -j 104 and probing on return vlaue of trylocks reveals: kernel`vm_page_pqbatch_submit _mtx_trylock_flags_int 0 5598217 kernel`vm_page_pqbatch_submit _mtx_trylock_flags_int 1 41540482 That is, over 10% of all trylocks here fail. This means there is an atomic op performed for trylock itself and then when attempting to actually lock which in turn slows down other threads. I did not bother measuring perf change, these lock are not /that/ contended yet. I presume trylocking is there to make it more likely we operate on the same queue, but likelihood of this happening should not meaningfully change with this patch. This makes vm_pagequeue_trylock unused in the tree, but I did not remove it just in case.

About 11 minutes of poudriere -s -j 104 and probing on return vlaue of trylocks reveals: kernel`vm_page_pqbatch_submit _mtx_trylock_flags_int 0 5598217 kernel`vm_page_pqbatch_submit _mtx_trylock_flags_int 1 41540482 That is, over 10% of all trylocks here fail. This means there is an atomic op performed for trylock itself and then when attempting to actually lock which in turn slows down other threads. I did not bother measuring perf change, these lock are not /that/ contended yet. I presume trylocking is there to make it more likely we operate on the same queue, but likelihood of this happening should not meaningfully change with this patch. The code can be modified to take a peek if it will want to process the queue. This makes vm_pagequeue_trylock unused in the tree, but I did not remove it just in case.

About 11 minutes of poudriere -s -j 104 and probing on return vlaue of trylocks reveals: kernel`vm_page_pqbatch_submit _mtx_trylock_flags_int 0 5598217 kernel`vm_page_pqbatch_submit _mtx_trylock_flags_int 1 41540482 That is, over 10% of all trylocks here fail. This means there is an atomic op performed for trylock itself and then when attempting to actually lock which in turn slows down other threads. I did not bother measuring perf change, these lock are not /that/ contended yet. I presume trylocking is there to make it more likely we operate on the same queue, but likelihood of this happening should not meaningfully change with this patch. The code can be modified to take a peek if it will want to process the queue. This makes vm_pagequeue_trylock unused in the tree, but I did not remove it just in case.