Re: [RFC] net: remove busylock

On Tue, 2016-05-24 at 13:50 +, David Laight wrote: > From: Jesper Dangaard Brouer > > Sent: 20 May 2016 18:50 > ... > > If would be cool if you could run a test with removed busylock and > > allow HTB to bulk dequeue. > > (Without having looked ) > Could you have two queues and separate

RE: [RFC] net: remove busylock

From: Jesper Dangaard Brouer > Sent: 20 May 2016 18:50 ... > If would be cool if you could run a test with removed busylock and > allow HTB to bulk dequeue. (Without having looked ) Could you have two queues and separate queue and dequeue locks. The enqueue code would acquire the enqueue

Re: [RFC] net: remove busylock

On Fri, 20 May 2016 14:32:40 -0700 Eric Dumazet wrote: > On Fri, 2016-05-20 at 19:49 +0200, Jesper Dangaard Brouer wrote: > > On Fri, 20 May 2016 07:16:55 -0700 > > Eric Dumazet wrote: > > > > > Since bonding pretends to be multiqueue,

Re: [RFC] net: remove busylock

On Fri, 2016-05-20 at 19:49 +0200, Jesper Dangaard Brouer wrote: > On Fri, 20 May 2016 07:16:55 -0700 > Eric Dumazet wrote: > > > Since bonding pretends to be multiqueue, TCQ_F_ONETXQUEUE is not set > > on sch->flags when HTB is installed at the bonding device root. > >

Re: [RFC] net: remove busylock

On Fri, 20 May 2016 07:16:55 -0700 Eric Dumazet wrote: > Since bonding pretends to be multiqueue, TCQ_F_ONETXQUEUE is not set > on sch->flags when HTB is installed at the bonding device root. If would be cool if you could run a test with removed busylock and allow HTB to

Re: [RFC] net: remove busylock

On 16-05-20 06:11 AM, Eric Dumazet wrote: > On Fri, 2016-05-20 at 09:29 +0200, Jesper Dangaard Brouer wrote: > > >> The hole idea behind allowing bulk qdisc dequeue, was to mitigate this, >> by allowing dequeue to do more work, while holding the lock. >> >> You mention HTB. Notice HTB does not

Re: [RFC] net: remove busylock

On Fri, 2016-05-20 at 06:47 -0700, Eric Dumazet wrote: > On Fri, 2016-05-20 at 06:11 -0700, Eric Dumazet wrote: > > On Fri, 2016-05-20 at 09:29 +0200, Jesper Dangaard Brouer wrote: > > > > > > > The hole idea behind allowing bulk qdisc dequeue, was to mitigate this, > > > by allowing dequeue to

Re: [RFC] net: remove busylock

On Fri, 2016-05-20 at 06:11 -0700, Eric Dumazet wrote: > On Fri, 2016-05-20 at 09:29 +0200, Jesper Dangaard Brouer wrote: > > > > The hole idea behind allowing bulk qdisc dequeue, was to mitigate this, > > by allowing dequeue to do more work, while holding the lock. > > > > You mention HTB.

Re: [RFC] net: remove busylock

On Fri, 2016-05-20 at 09:29 +0200, Jesper Dangaard Brouer wrote: > The hole idea behind allowing bulk qdisc dequeue, was to mitigate this, > by allowing dequeue to do more work, while holding the lock. > > You mention HTB. Notice HTB does not take advantage of bulk dequeue. > Have you tried to

Re: [RFC] net: remove busylock

On Thu, 19 May 2016 11:03:32 -0700 Alexander Duyck wrote: > On Thu, May 19, 2016 at 10:08 AM, Eric Dumazet wrote: > > busylock was added at the time we had expensive ticket spinlocks > > > > (commit 79640a4ca6955e3ebdb7038508fa7a0cd7fa5527

Re: [RFC] net: remove busylock

On Thu, 2016-05-19 at 21:49 -0700, John Fastabend wrote: > I plan to start looking at this again in June when I have some > more time FWIW. The last set of RFCs I sent out bypassed both the > qdisc lock and the busy poll lock. I remember thinking this was a > net win at the time but I only did

Re: [RFC] net: remove busylock

On 16-05-19 01:39 PM, Alexander Duyck wrote: > On Thu, May 19, 2016 at 12:35 PM, Eric Dumazet wrote: >> On Thu, 2016-05-19 at 11:56 -0700, Eric Dumazet wrote: >> >>> Removing busylock helped in all cases I tested. (at least on x86 as >>> David pointed out) >>> >>> As I

Re: [RFC] net: remove busylock

On Thu, May 19, 2016 at 12:35 PM, Eric Dumazet wrote: > On Thu, 2016-05-19 at 11:56 -0700, Eric Dumazet wrote: > >> Removing busylock helped in all cases I tested. (at least on x86 as >> David pointed out) >> >> As I said, we need to revisit busylock now that spinlocks are

Re: [RFC] net: remove busylock

On Thu, 2016-05-19 at 11:56 -0700, Eric Dumazet wrote: > Removing busylock helped in all cases I tested. (at least on x86 as > David pointed out) > > As I said, we need to revisit busylock now that spinlocks are different. > > In one case (20 concurrent UDP netperf), I even got a 500 %

Re: [RFC] net: remove busylock

On Thu, 2016-05-19 at 11:03 -0700, Alexander Duyck wrote: > On Thu, May 19, 2016 at 10:08 AM, Eric Dumazet wrote: > > busylock was added at the time we had expensive ticket spinlocks > > > > (commit 79640a4ca6955e3ebdb7038508fa7a0cd7fa5527 ("net: add additional > > lock to

Re: [RFC] net: remove busylock

On Thu, 2016-05-19 at 11:12 -0700, David Miller wrote: > From: Eric Dumazet > Date: Thu, 19 May 2016 10:08:36 -0700 > > > busylock was added at the time we had expensive ticket spinlocks > > > > (commit 79640a4ca6955e3ebdb7038508fa7a0cd7fa5527 ("net: add additional > >

Re: [RFC] net: remove busylock

On 05/19/2016 11:03 AM, Alexander Duyck wrote: On Thu, May 19, 2016 at 10:08 AM, Eric Dumazet wrote: With HTB qdisc, here are the numbers for 200 concurrent TCP_RR, on a host with 48 hyperthreads. ... That would be a 8 % increase. The main point of the busy lock

Re: [RFC] net: remove busylock

From: Eric Dumazet Date: Thu, 19 May 2016 10:08:36 -0700 > busylock was added at the time we had expensive ticket spinlocks > > (commit 79640a4ca6955e3ebdb7038508fa7a0cd7fa5527 ("net: add additional > lock to qdisc to increase throughput") > > Now kernel spinlocks are

Re: [RFC] net: remove busylock

On Thu, May 19, 2016 at 10:08 AM, Eric Dumazet wrote: > busylock was added at the time we had expensive ticket spinlocks > > (commit 79640a4ca6955e3ebdb7038508fa7a0cd7fa5527 ("net: add additional > lock to qdisc to increase throughput") > > Now kernel spinlocks are MCS,