Re: [patch 3/3] vmstat: Create our own workqueue

On Fri, 6 Nov 2015, Tetsuo Handa wrote: > So, if you refer to the blocking of the execution of vmstat updates, > description for patch 3/3 sould be updated to something like below? Ok that is much better. > -- > Since __GFP_WAIT memory allocations do not call schedule() > when there is

Re: [patch 3/3] vmstat: Create our own workqueue

Christoph Lameter wrote: > On Sat, 31 Oct 2015, Tetsuo Handa wrote: > > > Then, you need to update below description (or drop it) because > > patch 3/3 alone will not guarantee that the counters are up to date. > > The vmstat system does not guarantee that the counters are up to date > always.

Re: [patch 3/3] vmstat: Create our own workqueue

Christoph Lameter wrote: > On Sat, 31 Oct 2015, Tetsuo Handa wrote: > > > Then, you need to update below description (or drop it) because > > patch 3/3 alone will not guarantee that the counters are up to date. > > The vmstat system does not guarantee that the counters are up to date > always.

Re: [patch 3/3] vmstat: Create our own workqueue

On Fri, 6 Nov 2015, Tetsuo Handa wrote: > So, if you refer to the blocking of the execution of vmstat updates, > description for patch 3/3 sould be updated to something like below? Ok that is much better. > -- > Since __GFP_WAIT memory allocations do not call schedule() > when there is

Re: [patch 3/3] vmstat: Create our own workqueue

On Mon, Nov 02, 2015 at 12:10:04PM -0600, Christoph Lameter wrote: > Well true that is dependend on the correct workqueue operation. I though > that was fixed by Tejun? At least for now, we're going with Tetsuo's short sleep patch. Thanks. -- tejun -- To unsubscribe from this list: send the

Re: [patch 3/3] vmstat: Create our own workqueue

On Tue, 3 Nov 2015, Tetsuo Handa wrote: > I'm still unclear. I think that the result of this patchset is > > The counters are never updated even after stat_interval > if some workqueue item is doing a __GFP_WAIT memory allocation. > > but the patch description sounds as if > > The counters

Re: [patch 3/3] vmstat: Create our own workqueue

Christoph Lameter wrote: > On Sat, 31 Oct 2015, Tetsuo Handa wrote: > > > Then, you need to update below description (or drop it) because > > patch 3/3 alone will not guarantee that the counters are up to date. > > The vmstat system does not guarantee that the counters are up to date > always.

Re: [patch 3/3] vmstat: Create our own workqueue

On Sat, 31 Oct 2015, Tetsuo Handa wrote: > Then, you need to update below description (or drop it) because > patch 3/3 alone will not guarantee that the counters are up to date. The vmstat system does not guarantee that the counters are up to date always. The whole point is the deferral of

Re: [patch 3/3] vmstat: Create our own workqueue

On Tue, 3 Nov 2015, Tetsuo Handa wrote: > I'm still unclear. I think that the result of this patchset is > > The counters are never updated even after stat_interval > if some workqueue item is doing a __GFP_WAIT memory allocation. > > but the patch description sounds as if > > The counters

Re: [patch 3/3] vmstat: Create our own workqueue

On Mon, Nov 02, 2015 at 12:10:04PM -0600, Christoph Lameter wrote: > Well true that is dependend on the correct workqueue operation. I though > that was fixed by Tejun? At least for now, we're going with Tetsuo's short sleep patch. Thanks. -- tejun -- To unsubscribe from this list: send the

Re: [patch 3/3] vmstat: Create our own workqueue

On Sat, 31 Oct 2015, Tetsuo Handa wrote: > Then, you need to update below description (or drop it) because > patch 3/3 alone will not guarantee that the counters are up to date. The vmstat system does not guarantee that the counters are up to date always. The whole point is the deferral of

Re: [patch 3/3] vmstat: Create our own workqueue

Christoph Lameter wrote: > On Sat, 31 Oct 2015, Tetsuo Handa wrote: > > > Then, you need to update below description (or drop it) because > > patch 3/3 alone will not guarantee that the counters are up to date. > > The vmstat system does not guarantee that the counters are up to date > always.

Re: [patch 3/3] vmstat: Create our own workqueue

Christoph Lameter wrote: > On Thu, 29 Oct 2015, Tejun Heo wrote: > > > Wait, this series doesn't include Tetsuo's change. Of course it won't > > fix the deadlock problem. What's necessary is Tetsuo's patch + > > WQ_MEM_RECLAIM. > > This series is only dealing with vmstat changes. Do I get an

Re: [patch 3/3] vmstat: Create our own workqueue

On Thu, Oct 29, 2015 at 08:01:12PM -0500, Christoph Lameter wrote: > On Thu, 29 Oct 2015, Tejun Heo wrote: > > > Wait, this series doesn't include Tetsuo's change. Of course it won't > > fix the deadlock problem. What's necessary is Tetsuo's patch + > > WQ_MEM_RECLAIM. > > This series is only

Re: [patch 3/3] vmstat: Create our own workqueue

Christoph Lameter wrote: > On Thu, 29 Oct 2015, Tejun Heo wrote: > > > Wait, this series doesn't include Tetsuo's change. Of course it won't > > fix the deadlock problem. What's necessary is Tetsuo's patch + > > WQ_MEM_RECLAIM. > > This series is only dealing with vmstat changes. Do I get an

Re: [patch 3/3] vmstat: Create our own workqueue

On Thu, Oct 29, 2015 at 08:01:12PM -0500, Christoph Lameter wrote: > On Thu, 29 Oct 2015, Tejun Heo wrote: > > > Wait, this series doesn't include Tetsuo's change. Of course it won't > > fix the deadlock problem. What's necessary is Tetsuo's patch + > > WQ_MEM_RECLAIM. > > This series is only

Re: [patch 3/3] vmstat: Create our own workqueue

On Thu, 29 Oct 2015, Tejun Heo wrote: > Wait, this series doesn't include Tetsuo's change. Of course it won't > fix the deadlock problem. What's necessary is Tetsuo's patch + > WQ_MEM_RECLAIM. This series is only dealing with vmstat changes. Do I get an ack here? -- To unsubscribe from this

Re: [patch 3/3] vmstat: Create our own workqueue

On Thu, 29 Oct 2015, Tejun Heo wrote: > Wait, this series doesn't include Tetsuo's change. Of course it won't > fix the deadlock problem. What's necessary is Tetsuo's patch + > WQ_MEM_RECLAIM. This series is only dealing with vmstat changes. Do I get an ack here? -- To unsubscribe from this

Re: [patch 3/3] vmstat: Create our own workqueue

On Thu, Oct 29, 2015 at 11:24:47AM +0900, Tejun Heo wrote: > Hello, > > That's weird. > > On Wed, Oct 28, 2015 at 08:57:28PM +0900, Tetsuo Handa wrote: > > [ 272.851035] Showing busy workqueues and worker pools: > > [ 272.852583] workqueue events: flags=0x0 > > [ 272.853942] pwq 6: cpus=3

Re: [patch 3/3] vmstat: Create our own workqueue

Hello, That's weird. On Wed, Oct 28, 2015 at 08:57:28PM +0900, Tetsuo Handa wrote: > [ 272.851035] Showing busy workqueues and worker pools: > [ 272.852583] workqueue events: flags=0x0 > [ 272.853942] pwq 6: cpus=3 node=0 flags=0x0 nice=0 active=1/256 > [ 272.855781] pending:

Re: [patch 3/3] vmstat: Create our own workqueue

On Wed, 28 Oct 2015, Tetsuo Handa wrote: > Christoph Lameter wrote: > > On Wed, 28 Oct 2015, Tejun Heo wrote: > > > > > The only thing necessary here is WQ_MEM_RECLAIM. I don't see how > > > WQ_SYSFS and WQ_FREEZABLE make sense here. > > > I can still trigger silent livelock with this patchset

Re: [patch 3/3] vmstat: Create our own workqueue

Christoph Lameter wrote: > On Wed, 28 Oct 2015, Tejun Heo wrote: > > > The only thing necessary here is WQ_MEM_RECLAIM. I don't see how > > WQ_SYSFS and WQ_FREEZABLE make sense here. > I can still trigger silent livelock with this patchset applied. -- [ 272.283217] MemAlloc-Info: 9

Re: [patch 3/3] vmstat: Create our own workqueue

Christoph Lameter wrote: > On Wed, 28 Oct 2015, Tejun Heo wrote: > > > The only thing necessary here is WQ_MEM_RECLAIM. I don't see how > > WQ_SYSFS and WQ_FREEZABLE make sense here. > I can still trigger silent livelock with this patchset applied. -- [ 272.283217] MemAlloc-Info: 9

Re: [patch 3/3] vmstat: Create our own workqueue

On Thu, Oct 29, 2015 at 11:24:47AM +0900, Tejun Heo wrote: > Hello, > > That's weird. > > On Wed, Oct 28, 2015 at 08:57:28PM +0900, Tetsuo Handa wrote: > > [ 272.851035] Showing busy workqueues and worker pools: > > [ 272.852583] workqueue events: flags=0x0 > > [ 272.853942] pwq 6: cpus=3

Re: [patch 3/3] vmstat: Create our own workqueue

Hello, That's weird. On Wed, Oct 28, 2015 at 08:57:28PM +0900, Tetsuo Handa wrote: > [ 272.851035] Showing busy workqueues and worker pools: > [ 272.852583] workqueue events: flags=0x0 > [ 272.853942] pwq 6: cpus=3 node=0 flags=0x0 nice=0 active=1/256 > [ 272.855781] pending:

Re: [patch 3/3] vmstat: Create our own workqueue

On Wed, 28 Oct 2015, Tetsuo Handa wrote: > Christoph Lameter wrote: > > On Wed, 28 Oct 2015, Tejun Heo wrote: > > > > > The only thing necessary here is WQ_MEM_RECLAIM. I don't see how > > > WQ_SYSFS and WQ_FREEZABLE make sense here. > > > I can still trigger silent livelock with this patchset

Re: [patch 3/3] vmstat: Create our own workqueue

On Wed, 28 Oct 2015, Tejun Heo wrote: > The only thing necessary here is WQ_MEM_RECLAIM. I don't see how > WQ_SYSFS and WQ_FREEZABLE make sense here. Subject: vmstat: Remove WQ_FREEZABLE and WQ_SYSFS Signed-off-by: Christoph Lameter Index: linux/mm/vmstat.c

Re: [patch 3/3] vmstat: Create our own workqueue

Hello, On Tue, Oct 27, 2015 at 09:41:17PM -0500, Christoph Lameter wrote: > + vmstat_wq = alloc_workqueue("vmstat", > + WQ_FREEZABLE| > + WQ_SYSFS| > + WQ_MEM_RECLAIM, 0); The only thing necessary here is WQ_MEM_RECLAIM. I don't see how WQ_SYSFS and

[patch 3/3] vmstat: Create our own workqueue

Seems that vmstat needs its own workqueue now since the general workqueue mechanism has been *enhanced* which means that the vmstat_updates cannot run reliably but are being blocked by work requests doing memory allocation. Which causes vmstat to be unable to keep the counters up to date. Bad.

Re: [patch 3/3] vmstat: Create our own workqueue

Hello, On Tue, Oct 27, 2015 at 09:41:17PM -0500, Christoph Lameter wrote: > + vmstat_wq = alloc_workqueue("vmstat", > + WQ_FREEZABLE| > + WQ_SYSFS| > + WQ_MEM_RECLAIM, 0); The only thing necessary here is WQ_MEM_RECLAIM. I don't see how WQ_SYSFS and

Re: [patch 3/3] vmstat: Create our own workqueue

On Wed, 28 Oct 2015, Tejun Heo wrote: > The only thing necessary here is WQ_MEM_RECLAIM. I don't see how > WQ_SYSFS and WQ_FREEZABLE make sense here. Subject: vmstat: Remove WQ_FREEZABLE and WQ_SYSFS Signed-off-by: Christoph Lameter Index: linux/mm/vmstat.c

[patch 3/3] vmstat: Create our own workqueue

Seems that vmstat needs its own workqueue now since the general workqueue mechanism has been *enhanced* which means that the vmstat_updates cannot run reliably but are being blocked by work requests doing memory allocation. Which causes vmstat to be unable to keep the counters up to date. Bad.