Sorry, one last thing to confirm, is tstruk@gmail.com also your email address?

I assume the two piles in the bypass flamegraphs which don't start at fork_exit() are just because the stack sample isn't deep enough to correlate them over and that the iflib_txq_drain() samples in the wide peak are actually the ones that are directly in iflib_txq_drain?

I apologize, I wrote some off-topic remark not important in this review (please don't consider them),
thanks to add the sysctl name support to truss.

No I don't use it.

I agree with mark - this will be a nice cleanup and I think should be done, but will take some careful coordination with downstreams, and ports.

I have no objections to the change in principle, it's a nice cleanup. It would cause a massive amount of churn: we have about 2000 uses of mtod() in the tree, and downstream trees will have many thousands more. I think such a change deserves a wider discussion on -arch or so.

In D21649#472966, @lwhsu wrote:

Please let me know if you need me to commit this (and D21650, D21651, D21650).

• make vn_start_write_nb static
• add a comment explaining error handling
• assert LK_NOWAIT passed if LK_IGNORE_INTERLOCK is used

rS352446 should fix the alignment issues here.

I think it is fine.

This updates the patch set, the ktls.h information was incorrect. I also add the fixes
that Michael is doing on the Rack side to BBR as well (check for invalid length in non-tso case).

I don't see why this is sufficient. If the unlocked translation attempt fails, e.g., because the mapping is being promoted or demoted a second time, we may still attempt to acquire a mutex in a scenario where that is not allowed.

In D21667#472964, @mjg wrote:

I think it's cleaner to handle this separately mostly because this function cannot do any clean up so it behaves quite differently compared to vn_start_write. If you insist I can fold it in.