lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 02 Sep 2014 11:35:20 +0800 From: Jason Wang <jasowang@...hat.com> To: Eliezer Tamir <eliezer.tamir@...ux.intel.com>, Eric Dumazet <eric.dumazet@...il.com> CC: Ingo Molnar <mingo@...nel.org>, Mike Galbraith <umgwanakikbuti@...il.com>, davem@...emloft.net, netdev@...r.kernel.org, linux-kernel@...r.kernel.org, mst@...hat.com, Peter Zijlstra <peterz@...radead.org>, "Ingo Molnar jacob.e.keller@...el.com" <mingo@...e.hu> Subject: Re: [PATCH net-next 2/2] net: exit busy loop when another process is runnable 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 majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists