Re: [GIT PULL] workqueue fixes for v4.5-rc3

On Thu, Feb 11, 2016 at 10:49 AM, Thomas Gleixner wrote: > > while playing around with it and wondering where to put the command line > option, I wondered whether it makes sense to tie this to debugobjects. > > If stuff goes bad, then state corruptions of the involved objects (timers, > work ..)

Re: [GIT PULL] workqueue fixes for v4.5-rc3

Linus, On Thu, 11 Feb 2016, Linus Torvalds wrote: > On Thu, Feb 11, 2016 at 12:18 AM, Thomas Gleixner wrote: > > > > That certainly makes sense. So we should use a common debug option to force > > the 'schedule remote' machinery for all interesting subsystems instead of > > creating an extra

Re: [GIT PULL] workqueue fixes for v4.5-rc3

On Thu, Feb 11, 2016 at 12:18 AM, Thomas Gleixner wrote: > > That certainly makes sense. So we should use a common debug option to force > the 'schedule remote' machinery for all interesting subsystems instead of > creating an extra option for each. Yeah, let's make it easy to use and enable.

Re: [GIT PULL] workqueue fixes for v4.5-rc3

On Wed, 10 Feb 2016, Linus Torvalds wrote: > On Wed, Feb 10, 2016 at 9:25 AM, Tejun Heo wrote: > > > > * Officially break local execution guarantee of unbound work items and > > add a debug feature to flush out usages which depend on it. > > Btw, should we try to do this for timers too? A

Re: [GIT PULL] workqueue fixes for v4.5-rc3

On Wed, 10 Feb 2016, Linus Torvalds wrote: > On Wed, Feb 10, 2016 at 9:25 AM, Tejun Heo wrote: > > > > * Officially break local execution guarantee of unbound work items and > > add a debug feature to flush out usages which depend on it. > > Btw, should we try to do this for

Re: [GIT PULL] workqueue fixes for v4.5-rc3

Linus, On Thu, 11 Feb 2016, Linus Torvalds wrote: > On Thu, Feb 11, 2016 at 12:18 AM, Thomas Gleixner wrote: > > > > That certainly makes sense. So we should use a common debug option to force > > the 'schedule remote' machinery for all interesting subsystems instead of > >

Re: [GIT PULL] workqueue fixes for v4.5-rc3

On Thu, Feb 11, 2016 at 10:49 AM, Thomas Gleixner wrote: > > while playing around with it and wondering where to put the command line > option, I wondered whether it makes sense to tie this to debugobjects. > > If stuff goes bad, then state corruptions of the involved objects

Re: [GIT PULL] workqueue fixes for v4.5-rc3

On Thu, Feb 11, 2016 at 12:18 AM, Thomas Gleixner wrote: > > That certainly makes sense. So we should use a common debug option to force > the 'schedule remote' machinery for all interesting subsystems instead of > creating an extra option for each. Yeah, let's make it easy

Re: [GIT PULL] workqueue fixes for v4.5-rc3

On Wed, Feb 10, 2016 at 9:25 AM, Tejun Heo wrote: > > * Officially break local execution guarantee of unbound work items and > add a debug feature to flush out usages which depend on it. Btw, should we try to do this for timers too? A debug option to make a regular "add_timer()" explicitly

[GIT PULL] workqueue fixes for v4.5-rc3

Hello, Linus. Workqueue fixes for v4.5-rc3. * Remove a spurious triggering of flush dependency warning. * Officially break local execution guarantee of unbound work items and add a debug feature to flush out usages which depend on it. * Work around CPU -> NODE mapping becoming invalid on CPU

[GIT PULL] workqueue fixes for v4.5-rc3

Hello, Linus. Workqueue fixes for v4.5-rc3. * Remove a spurious triggering of flush dependency warning. * Officially break local execution guarantee of unbound work items and add a debug feature to flush out usages which depend on it. * Work around CPU -> NODE mapping becoming invalid on CPU

Re: [GIT PULL] workqueue fixes for v4.5-rc3

On Wed, Feb 10, 2016 at 9:25 AM, Tejun Heo wrote: > > * Officially break local execution guarantee of unbound work items and > add a debug feature to flush out usages which depend on it. Btw, should we try to do this for timers too? A debug option to make a regular