On 16.09.2021 17:04, Tamas K Lengyel wrote:
> During fork reset operation the parent domain doesn't need to be gathered
> using
> rcu_lock_live_remote_domain_by_id as the fork reset doesn't modify anything on
> the parent. The parent is also guaranteed to be paused while forks are active.
> This patch reduces lock contention when performing resets in parallel.
I'm a little in trouble following you here: RCU locks aren't really
locks in that sense, so "lock contention" seems misleading to me. I
can see that rcu_lock_domain_by_id()'s loop is extra overhead.
Furthermore - does the parent being paused really mean the parent
can't go away behind the back of the fork reset? In fork() I see
if ( rc && rc != -ERESTART )
{
domain_unpause(d);
put_domain(d);
cd->parent = NULL;
}
i.e. the ref gets dropped before the parent pointer gets cleared. If
the parent having a reference kept was indeed properly guaranteed, I
agree the code change itself is fine.
(The sequence looks correct at the other put_domain() site [dealing
with the success case of fork(), when the reference gets retained]
in domain_relinquish_resources().)
Jan
