On Wed, Nov 26, 2025 at 1:31 PM Ian Forbes <[email protected]> wrote: > > On Thu, Nov 20, 2025 at 10:43 AM Zack Rusin <[email protected]> wrote: > > > > > This bit looks suspicious. It looks like if ctx->merge_dups is false > > and the resource is doomed then we'll try to remove an invalid node > > (because it has not been added to the hash). > > > > Other than that, it looks great. > > > > > > z > > It does look suspicious but since the hashtable is intrusive we are > just nulling out the node which is still zeroed at this point.
BTW hash initialization, you've removed the vmw_sw_context_init that
was calling hash_init and started relying on .res_ht = {}, which while
should work right now because hlist just wants the pointers nulled, it
might break in the future because we're not exactly following the hash
api. I think at the very least we want to call hash_init after
DECLARE_VAL_CONTEXT to properly initialize that hashtable. Anyway, I'd
probably shield that deletion just in case anyway, even if it's just
because it looks confusing.
Did lowering the VMW_RES_HT_ORDER affect any of the benchmarks? e.g.
unigine heaven or valley ?
z
smime.p7s
Description: S/MIME Cryptographic Signature
