On 09/01/2014 02:55 PM, Eliezer Tamir wrote: > On 26/08/2014 10:16, Jason Wang wrote: >> On 08/25/2014 09:16 PM, Eliezer Tamir wrote: >>> Here are my 2 cents: >>> I think Ingo's suggestion of only yielding to tasks with same or higher >>> priority makes sense. >> I'm not sure I get your meaning. Do you mean calling yield_to() directly >> in sk_busy_loop? > Think about the case where two processes are busy polling on the > same CPU and the same device queue. Since busy polling processes > incoming packets on the queue from any process, this scenario works > well currently,
I see, but looks like we can simply do this by exiting the busy loop when ndo_busy_poll() finds something but not for current socket? > and will not work at all when polling yields to other > processes that are of the same priority that are running on the same > CPU. So yielding has its limitation, we need let scheduler to do the choice instead. > > As a side note, there is a lot of room for improvement when two > processes on the same CPU want to busy poll on different device > queues. > The RFC code I published for epoll support showed one possible > way of solving this, but I'm sure that there are other possibilities. > > Maybe the networking subsystem should maintain a list of device > queues that need busypolling and have a thread that would poll > all of them when there's nothing better to do. Not sure whether this method will scale considering thousands of sockets and processes. > > I'm aware of similar work on busy polling on NVMe devices, so > maybe there should be a global busypoll thread for all devices > that support it. > > BTW, I have someone inside Intel that wants to test future patches. Feel > free to send me patches for testing, even if they are not ready for > publishing yet. > > Cheers, > Eliezer Ok, will do it, thanks a lot. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/