Re: [PATCH v3] trace/pid_list: optimize pid_list->lock contention

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

On 2025-11-13 08:02:52 [+0800], Yongliang Gao wrote:
> --- a/kernel/trace/pid_list.c
> +++ b/kernel/trace/pid_list.c
> @@ -138,14 +139,16 @@ bool trace_pid_list_is_set(struct trace_pid_list *pid_list, unsigned int pid)
>  	if (pid_split(pid, &upper1, &upper2, &lower) < 0)
>  		return false;
>  
> -	raw_spin_lock_irqsave(&pid_list->lock, flags);
> -	upper_chunk = pid_list->upper[upper1];
> -	if (upper_chunk) {
> -		lower_chunk = upper_chunk->data[upper2];
> -		if (lower_chunk)
> -			ret = test_bit(lower, lower_chunk->data);
> -	}
> -	raw_spin_unlock_irqrestore(&pid_list->lock, flags);
> +	do {
> +		seq = read_seqcount_begin(&pid_list->seqcount);
> +		ret = false;
> +		upper_chunk = pid_list->upper[upper1];
> +		if (upper_chunk) {
> +			lower_chunk = upper_chunk->data[upper2];
> +			if (lower_chunk)
> +				ret = test_bit(lower, lower_chunk->data);
> +		}
> +	} while (read_seqcount_retry(&pid_list->seqcount, seq));

How is this better? Any numbers?
If the write side is busy and the lock is handed over from one CPU to
another then it is possible that the reader spins here and does several
loops, right?
And in this case, how accurate would it be? I mean the result could
change right after the sequence here is completed because the write side
got active again. How bad would it be if there would be no locking and
RCU ensures that the chunks (and data) don't disappear while looking at
it?

>  	return ret;
>  }

Sebastian