Re: net/sched: latent livelock in dev_deactivate_many() due to yield() usage

On Thu, Apr 06, 2017 at 12:28:44PM +0200, Peter Zijlstra wrote: > On Wed, Apr 05, 2017 at 05:31:05PM -0700, Stephen Hemminger wrote: > > On Sun, 02 Apr 2017 06:28:41 +0200 > > Mike Galbraith wrote: > > > > > Livelock can be triggered by setting kworkers to SCHED_FIFO, then > > >

Re: net/sched: latent livelock in dev_deactivate_many() due to yield() usage

On Thu, Apr 06, 2017 at 12:28:44PM +0200, Peter Zijlstra wrote: > On Wed, Apr 05, 2017 at 05:31:05PM -0700, Stephen Hemminger wrote: > > On Sun, 02 Apr 2017 06:28:41 +0200 > > Mike Galbraith wrote: > > > > > Livelock can be triggered by setting kworkers to SCHED_FIFO, then > > > suspend/resume..

Re: net/sched: latent livelock in dev_deactivate_many() due to yield() usage

On Wed, Apr 05, 2017 at 05:31:05PM -0700, Stephen Hemminger wrote: > On Sun, 02 Apr 2017 06:28:41 +0200 > Mike Galbraith wrote: > > > Livelock can be triggered by setting kworkers to SCHED_FIFO, then > > suspend/resume.. you come back from sleepy-land with a spinning > > kworker.

Re: net/sched: latent livelock in dev_deactivate_many() due to yield() usage

On Wed, Apr 05, 2017 at 05:31:05PM -0700, Stephen Hemminger wrote: > On Sun, 02 Apr 2017 06:28:41 +0200 > Mike Galbraith wrote: > > > Livelock can be triggered by setting kworkers to SCHED_FIFO, then > > suspend/resume.. you come back from sleepy-land with a spinning > > kworker. For whatever

Re: net/sched: latent livelock in dev_deactivate_many() due to yield() usage

On Tue, Apr 04, 2017 at 10:25:19PM -0700, Cong Wang wrote: > On Tue, Apr 4, 2017 at 8:20 PM, Mike Galbraith wrote: > > - while (some_qdisc_is_busy(dev)) > > - yield(); > > + swait_event_timeout(swait, !some_qdisc_is_busy(dev), 1); >

Re: net/sched: latent livelock in dev_deactivate_many() due to yield() usage

On Tue, Apr 04, 2017 at 10:25:19PM -0700, Cong Wang wrote: > On Tue, Apr 4, 2017 at 8:20 PM, Mike Galbraith wrote: > > - while (some_qdisc_is_busy(dev)) > > - yield(); > > + swait_event_timeout(swait, !some_qdisc_is_busy(dev), 1); > > } > > I

Re: net/sched: latent livelock in dev_deactivate_many() due to yield() usage

On Wed, 2017-04-05 at 17:31 -0700, Stephen Hemminger wrote: > On Sun, 02 Apr 2017 06:28:41 +0200 > Mike Galbraith wrote: > > > Livelock can be triggered by setting kworkers to SCHED_FIFO, then > > suspend/resume.. you come back from sleepy-land with a spinning > > kworker. For

Re: net/sched: latent livelock in dev_deactivate_many() due to yield() usage

On Wed, 2017-04-05 at 17:31 -0700, Stephen Hemminger wrote: > On Sun, 02 Apr 2017 06:28:41 +0200 > Mike Galbraith wrote: > > > Livelock can be triggered by setting kworkers to SCHED_FIFO, then > > suspend/resume.. you come back from sleepy-land with a spinning > > kworker. For whatever reason,

Re: net/sched: latent livelock in dev_deactivate_many() due to yield() usage

On Wed, 2017-04-05 at 16:55 -0700, Cong Wang wrote: > On Tue, Apr 4, 2017 at 11:12 PM, Mike Galbraith wrote: > > On Tue, 2017-04-04 at 22:25 -0700, Cong Wang wrote: > > > On Tue, Apr 4, 2017 at 8:20 PM, Mike Galbraith wrote: > > > > - while

Re: net/sched: latent livelock in dev_deactivate_many() due to yield() usage

On Wed, 2017-04-05 at 16:55 -0700, Cong Wang wrote: > On Tue, Apr 4, 2017 at 11:12 PM, Mike Galbraith wrote: > > On Tue, 2017-04-04 at 22:25 -0700, Cong Wang wrote: > > > On Tue, Apr 4, 2017 at 8:20 PM, Mike Galbraith wrote: > > > > - while (some_qdisc_is_busy(dev)) > > > > -

Re: net/sched: latent livelock in dev_deactivate_many() due to yield() usage

On Sun, 02 Apr 2017 06:28:41 +0200 Mike Galbraith wrote: > Livelock can be triggered by setting kworkers to SCHED_FIFO, then > suspend/resume.. you come back from sleepy-land with a spinning > kworker. For whatever reason, I can only do that with an enterprise > like config, my

Re: net/sched: latent livelock in dev_deactivate_many() due to yield() usage

On Sun, 02 Apr 2017 06:28:41 +0200 Mike Galbraith wrote: > Livelock can be triggered by setting kworkers to SCHED_FIFO, then > suspend/resume.. you come back from sleepy-land with a spinning > kworker. For whatever reason, I can only do that with an enterprise > like config, my standard config

Re: net/sched: latent livelock in dev_deactivate_many() due to yield() usage

On Tue, Apr 4, 2017 at 11:12 PM, Mike Galbraith wrote: > On Tue, 2017-04-04 at 22:25 -0700, Cong Wang wrote: >> On Tue, Apr 4, 2017 at 8:20 PM, Mike Galbraith wrote: >> > - while (some_qdisc_is_busy(dev)) >> > - yield(); >> > +

Re: net/sched: latent livelock in dev_deactivate_many() due to yield() usage

On Tue, Apr 4, 2017 at 11:12 PM, Mike Galbraith wrote: > On Tue, 2017-04-04 at 22:25 -0700, Cong Wang wrote: >> On Tue, Apr 4, 2017 at 8:20 PM, Mike Galbraith wrote: >> > - while (some_qdisc_is_busy(dev)) >> > - yield(); >> > +

Re: net/sched: latent livelock in dev_deactivate_many() due to yield() usage

On Tue, 2017-04-04 at 22:25 -0700, Cong Wang wrote: > On Tue, Apr 4, 2017 at 8:20 PM, Mike Galbraith wrote: > > - while (some_qdisc_is_busy(dev)) > > - yield(); > > + swait_event_timeout(swait, > > !some_qdisc_is_busy(dev), 1); > >

Re: net/sched: latent livelock in dev_deactivate_many() due to yield() usage

On Tue, 2017-04-04 at 22:25 -0700, Cong Wang wrote: > On Tue, Apr 4, 2017 at 8:20 PM, Mike Galbraith wrote: > > - while (some_qdisc_is_busy(dev)) > > - yield(); > > + swait_event_timeout(swait, > > !some_qdisc_is_busy(dev), 1); > > } > > I don't

Re: net/sched: latent livelock in dev_deactivate_many() due to yield() usage

On Tue, Apr 4, 2017 at 8:20 PM, Mike Galbraith wrote: > - while (some_qdisc_is_busy(dev)) > - yield(); > + swait_event_timeout(swait, !some_qdisc_is_busy(dev), 1); > } I don't see why this is an improvement even if I don't care

Re: net/sched: latent livelock in dev_deactivate_many() due to yield() usage

On Tue, Apr 4, 2017 at 8:20 PM, Mike Galbraith wrote: > - while (some_qdisc_is_busy(dev)) > - yield(); > + swait_event_timeout(swait, !some_qdisc_is_busy(dev), 1); > } I don't see why this is an improvement even if I don't care about the

Re: net/sched: latent livelock in dev_deactivate_many() due to yield() usage

On Tue, 2017-04-04 at 15:39 -0700, Cong Wang wrote: > Thanks for the report! Looks like a quick solution here is to replace > this yield() with cond_resched(), it is harder to really wait for > all qdisc's to transmit all packets. No, cond_resched() won't help. What I did is below, but I

Re: net/sched: latent livelock in dev_deactivate_many() due to yield() usage

On Tue, 2017-04-04 at 15:39 -0700, Cong Wang wrote: > Thanks for the report! Looks like a quick solution here is to replace > this yield() with cond_resched(), it is harder to really wait for > all qdisc's to transmit all packets. No, cond_resched() won't help. What I did is below, but I

Re: net/sched: latent livelock in dev_deactivate_many() due to yield() usage

On Sat, Apr 1, 2017 at 9:28 PM, Mike Galbraith wrote: > Greetings network wizards, > > Quoting kernel/sched/core.c: > /** > * yield - yield the current processor to other threads. > * > * Do not ever use this function, there's a 99% chance you're doing it wrong. > * > * The

Re: net/sched: latent livelock in dev_deactivate_many() due to yield() usage

On Sat, Apr 1, 2017 at 9:28 PM, Mike Galbraith wrote: > Greetings network wizards, > > Quoting kernel/sched/core.c: > /** > * yield - yield the current processor to other threads. > * > * Do not ever use this function, there's a 99% chance you're doing it wrong. > * > * The scheduler is at

net/sched: latent livelock in dev_deactivate_many() due to yield() usage

Greetings network wizards, Quoting kernel/sched/core.c: /** * yield - yield the current processor to other threads. * * Do not ever use this function, there's a 99% chance you're doing it wrong. * * The scheduler is at all times free to pick the calling task as the most * eligible task to

net/sched: latent livelock in dev_deactivate_many() due to yield() usage

Greetings network wizards, Quoting kernel/sched/core.c: /** * yield - yield the current processor to other threads. * * Do not ever use this function, there's a 99% chance you're doing it wrong. * * The scheduler is at all times free to pick the calling task as the most * eligible task to