Thread (27 messages) 27 messages, 6 authors, 2021-02-26

Re: [PATCH net] net: fix race between napi kthread mode and busy poll

From: Wei Wang <hidden>
Date: 2021-02-25 02:32:51

Possibly related (same subject, not in this thread)

On Wed, Feb 24, 2021 at 6:03 PM Jakub Kicinski [off-list ref] wrote:
On Thu, 25 Feb 2021 01:22:08 +0000 Alexander Duyck wrote:
quoted
Yeah, that was the patch Wei had done earlier. Eric complained about the extra set_bit atomic operation in the threaded path. That is when I came up with the idea of just adding a bit to the busy poll logic so that the only extra cost in the threaded path was having to check 2 bits instead of 1.
Maybe we can set the bit only if the thread is running? When thread
comes out of schedule() it can be sure that it has an NAPI to service.
But when it enters napi_thread_wait() and before it hits schedule()
it must be careful to make sure the NAPI is still (or already in the
very first run after creation) owned by it.
Are you suggesting setting the SCHED_THREAD bit in napi_thread_wait()
somewhere instead of in ____napi_schedule() as you previously plotted?
What does it help? I think if we have to do an extra set_bit(), it
seems cleaner to set it in ____napi_schedule(). This would solve the
warning issue as well.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help