Re: [PATCH v10 2/5] io-uring: add napi busy poll support

[Jens Axboe <axboe@kernel.dk>]

On 4/26/23 8:56?PM, Ammar Faizi wrote:
> On Tue, Apr 25, 2023 at 11:18:42AM -0700, Stefan Roesch wrote:
>> +void __io_napi_add(struct io_ring_ctx *ctx, struct file *file)
>> +{
>> +	unsigned int napi_id;
>> +	struct socket *sock;
>> +	struct sock *sk;
>> +	struct io_napi_ht_entry *he;
>> +
>> +	sock = sock_from_file(file);
>> +	if (!sock)
>> +		return;
>> +
>> +	sk = sock->sk;
>> +	if (!sk)
>> +		return;
>> +
>> +	napi_id = READ_ONCE(sk->sk_napi_id);
>> +
>> +	/* Non-NAPI IDs can be rejected. */
>> +	if (napi_id < MIN_NAPI_ID)
>> +		return;
>> +
>> +	spin_lock(&ctx->napi_lock);
>> +	hash_for_each_possible(ctx->napi_ht, he, node, napi_id) {
>> +		if (he->napi_id == napi_id) {
>> +			he->timeout = jiffies + NAPI_TIMEOUT;
>> +			goto out;
>> +		}
>> +	}
>> +
>> +	he = kmalloc(sizeof(*he), GFP_NOWAIT);
>> +	if (!he)
>> +		goto out;
>> +
>> +	he->napi_id = napi_id;
>> +	he->timeout = jiffies + NAPI_TIMEOUT;
>> +	hash_add(ctx->napi_ht, &he->node, napi_id);
>> +
>> +	list_add_tail(&he->list, &ctx->napi_list);
>> +
>> +out:
>> +	spin_unlock(&ctx->napi_lock);
>> +}
> 
> What about using GFP_KERNEL to allocate 'he' outside the spin lock, then
> kfree() it in the (he->napi_id == napi_id) path after unlock?

We actually discussed this in previous versions of this, it kind of
optimizes for the wrong thing. Only the first trip through here should
allocate a 'he' unit, the rest will find it on the hash. That means that
now the common case will alloc+free an extra one, pointlessly.

> That would make the critical section shorter. Also, GFP_NOWAIT is likely
> to fail under memory pressure.

If a ~48 byte allocation fails, then I suspect we have more serious
issues at hand rather than ignoring NAPI for this socket!

-- 
Jens Axboe