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. Worst case we can steal the queue before taking the lock, but I don't think that wins anything of significance.
This makes vm_pagequeue_trylock unused in the tree, but I did not remove it just in case.