Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1282624 > unrolled thread

[PATCH 1/2] watchdog: introduce touch_softlockup_watchdog_sched()

Started byTejun Heo <tj@kernel.org>
First post2015-12-03 01:30 +0100
Last post2015-12-03 16:10 +0100
Articles 7 on this page of 27 — 5 participants

Back to article view | Back to linux.kernel

Contents

  [PATCH 1/2] watchdog: introduce touch_softlockup_watchdog_sched() Tejun Heo <tj@kernel.org> - 2015-12-03 01:30 +0100
    [PATCH 2/2] workqueue: implement lockup detector Tejun Heo <tj@kernel.org> - 2015-12-03 01:30 +0100
      Re: [PATCH 2/2] workqueue: implement lockup detector Tejun Heo <tj@kernel.org> - 2015-12-03 15:50 +0100
      Re: [PATCH 2/2] workqueue: implement lockup detector Don Zickus <dzickus@redhat.com> - 2015-12-03 19:00 +0100
        Re: [PATCH 2/2] workqueue: implement lockup detector Tejun Heo <tj@kernel.org> - 2015-12-03 20:50 +0100
          Re: [PATCH 2/2] workqueue: implement lockup detector Ulrich Obergfell <uobergfe@redhat.com> - 2015-12-03 21:20 +0100
            Re: [PATCH 2/2] workqueue: implement lockup detector Tejun Heo <tj@kernel.org> - 2015-12-03 22:00 +0100
              Re: [PATCH 2/2] workqueue: implement lockup detector Ingo Molnar <mingo@kernel.org> - 2015-12-04 09:10 +0100
                Re: [PATCH 2/2] workqueue: implement lockup detector Don Zickus <dzickus@redhat.com> - 2015-12-04 18:00 +0100
              Re: [PATCH 2/2] workqueue: implement lockup detector Ulrich Obergfell <uobergfe@redhat.com> - 2015-12-04 14:30 +0100
      [PATCH v2 2/2] workqueue: implement lockup detector Tejun Heo <tj@kernel.org> - 2015-12-07 20:10 +0100
        Re: [PATCH v2 2/2] workqueue: implement lockup detector Tejun Heo <tj@kernel.org> - 2015-12-07 22:40 +0100
          Re: [PATCH v2 2/2] workqueue: implement lockup detector Don Zickus <dzickus@redhat.com> - 2015-12-08 17:10 +0100
            Re: [PATCH v2 2/2] workqueue: implement lockup detector Tejun Heo <tj@kernel.org> - 2015-12-08 17:40 +0100
        Re: [PATCH v2 2/2] workqueue: implement lockup detector Don Zickus <dzickus@redhat.com> - 2015-12-07 22:40 +0100
    Re: [PATCH 1/2] watchdog: introduce touch_softlockup_watchdog_sched() Peter Zijlstra <peterz@infradead.org> - 2015-12-03 10:40 +0100
      Re: [PATCH 1/2] watchdog: introduce touch_softlockup_watchdog_sched() Peter Zijlstra <peterz@infradead.org> - 2015-12-03 11:10 +0100
        Re: [PATCH 1/2] watchdog: introduce touch_softlockup_watchdog_sched() Tejun Heo <tj@kernel.org> - 2015-12-03 15:50 +0100
          Re: [PATCH 1/2] watchdog: introduce touch_softlockup_watchdog_sched() Tejun Heo <tj@kernel.org> - 2015-12-03 16:10 +0100
            [PATCH] workqueue: warn if memory reclaim tries to flush  !WQ_MEM_RECLAIM workqueue Tejun Heo <tj@kernel.org> - 2015-12-03 20:30 +0100
              Re: [PATCH] workqueue: warn if memory reclaim tries to flush  !WQ_MEM_RECLAIM workqueue Peter Zijlstra <peterz@infradead.org> - 2015-12-03 21:50 +0100
                Re: [PATCH] workqueue: warn if memory reclaim tries to flush  !WQ_MEM_RECLAIM workqueue Tejun Heo <tj@kernel.org> - 2015-12-03 22:00 +0100
                  Re: [PATCH] workqueue: warn if memory reclaim tries to flush  !WQ_MEM_RECLAIM workqueue Peter Zijlstra <peterz@infradead.org> - 2015-12-03 22:10 +0100
                    Re: [PATCH] workqueue: warn if memory reclaim tries to flush  !WQ_MEM_RECLAIM workqueue Tejun Heo <tj@kernel.org> - 2015-12-03 23:10 +0100
                      Re: [PATCH] workqueue: warn if memory reclaim tries to flush  !WQ_MEM_RECLAIM workqueue Peter Zijlstra <peterz@infradead.org> - 2015-12-04 14:00 +0100
              Re: [PATCH] workqueue: warn if memory reclaim tries to flush  !WQ_MEM_RECLAIM workqueue Tejun Heo <tj@kernel.org> - 2015-12-07 17:00 +0100
          Re: [PATCH 1/2] watchdog: introduce touch_softlockup_watchdog_sched() Peter Zijlstra <peterz@infradead.org> - 2015-12-03 16:10 +0100

Page 2 of 2 — ← Prev page 1 [2]

#1283327 — Re: [PATCH] workqueue: warn if memory reclaim tries to flush !WQ_MEM_RECLAIM workqueue

FromPeter Zijlstra <peterz@infradead.org>
Date2015-12-03 21:50 +0100
SubjectRe: [PATCH] workqueue: warn if memory reclaim tries to flush !WQ_MEM_RECLAIM workqueue
Message-ID<qBIZb-1y2-5@gated-at.bofh.it>
In reply to#1283274
On Thu, Dec 03, 2015 at 02:26:16PM -0500, Tejun Heo wrote:
> +	WARN_ONCE(current->flags & PF_MEMALLOC,

I'm not sure about using PF_MEMALLOC for detecting reclaim. There appear
to be more sites setting this than reclaim. See:

drivers/block/nbd.c:	current->flags |= PF_MEMALLOC;
drivers/mmc/card/queue.c:	current->flags |= PF_MEMALLOC;
drivers/mtd/nand/nandsim.c:	current->flags |= PF_MEMALLOC;
drivers/scsi/iscsi_tcp.c:	current->flags |= PF_MEMALLOC;
drivers/staging/lustre/include/linux/libcfs/linux/linux-mem.h:#define memory_pressure_set() do { current->flags |= PF_MEMALLOC; } while (0)
fs/cifs/connect.c:	current->flags |= PF_MEMALLOC;
fs/xfs/libxfs/xfs_btree.c:		new_pflags |= PF_MEMALLOC | PF_SWAPWRITE | PF_KSWAPD;
fs/xfs/xfs_trans_ail.c:	current->flags |= PF_MEMALLOC;
include/linux/sched.h:	current->flags |= PF_MEMALLOC_NOIO;
mm/page_alloc.c:	current->flags |= PF_MEMALLOC;
mm/page_alloc.c:	current->flags |= PF_MEMALLOC;
mm/vmscan.c:	tsk->flags |= PF_MEMALLOC | PF_SWAPWRITE | PF_KSWAPD;
mm/vmscan.c:	p->flags |= PF_MEMALLOC;
mm/vmscan.c:	p->flags |= PF_MEMALLOC | PF_SWAPWRITE;
net/core/dev.c:		current->flags |= PF_MEMALLOC;
net/core/sock.c:	current->flags |= PF_MEMALLOC;


The actual reclaim sites in page_alloc and vmscan set
current->reclaim_state. So testing against that might be more accurate.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1283346 — Re: [PATCH] workqueue: warn if memory reclaim tries to flush !WQ_MEM_RECLAIM workqueue

FromTejun Heo <tj@kernel.org>
Date2015-12-03 22:00 +0100
SubjectRe: [PATCH] workqueue: warn if memory reclaim tries to flush !WQ_MEM_RECLAIM workqueue
Message-ID<qBJ8T-1Cs-61@gated-at.bofh.it>
In reply to#1283327
Hey, Peter.

On Thu, Dec 03, 2015 at 09:43:13PM +0100, Peter Zijlstra wrote:
> I'm not sure about using PF_MEMALLOC for detecting reclaim. There appear
> to be more sites setting this than reclaim. See:
>
> drivers/block/nbd.c:	current->flags |= PF_MEMALLOC;
> drivers/mmc/card/queue.c:	current->flags |= PF_MEMALLOC;
> drivers/mtd/nand/nandsim.c:	current->flags |= PF_MEMALLOC;
> drivers/scsi/iscsi_tcp.c:	current->flags |= PF_MEMALLOC;
> drivers/staging/lustre/include/linux/libcfs/linux/linux-mem.h:#define memory_pressure_set() do { current->flags |= PF_MEMALLOC; } while (0)
> fs/cifs/connect.c:	current->flags |= PF_MEMALLOC;
> fs/xfs/libxfs/xfs_btree.c:		new_pflags |= PF_MEMALLOC | PF_SWAPWRITE | PF_KSWAPD;
> fs/xfs/xfs_trans_ail.c:	current->flags |= PF_MEMALLOC;
> include/linux/sched.h:	current->flags |= PF_MEMALLOC_NOIO;
> mm/page_alloc.c:	current->flags |= PF_MEMALLOC;
> mm/page_alloc.c:	current->flags |= PF_MEMALLOC;
> mm/vmscan.c:	tsk->flags |= PF_MEMALLOC | PF_SWAPWRITE | PF_KSWAPD;
> mm/vmscan.c:	p->flags |= PF_MEMALLOC;
> mm/vmscan.c:	p->flags |= PF_MEMALLOC | PF_SWAPWRITE;
> net/core/dev.c:		current->flags |= PF_MEMALLOC;
> net/core/sock.c:	current->flags |= PF_MEMALLOC;
> 
> 
> The actual reclaim sites in page_alloc and vmscan set
> current->reclaim_state. So testing against that might be more accurate.

So, if I'm not mistaken, those are all marking tasks which can be
depended upon during memory reclaim and we do want to catch them all.
PF_MEMALLOC shouldn't depend on something which require memory to be
reclaimed to guarantee forward progress.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1283364 — Re: [PATCH] workqueue: warn if memory reclaim tries to flush !WQ_MEM_RECLAIM workqueue

FromPeter Zijlstra <peterz@infradead.org>
Date2015-12-03 22:10 +0100
SubjectRe: [PATCH] workqueue: warn if memory reclaim tries to flush !WQ_MEM_RECLAIM workqueue
Message-ID<qBJiz-1Vy-33@gated-at.bofh.it>
In reply to#1283346
On Thu, Dec 03, 2015 at 03:56:32PM -0500, Tejun Heo wrote:
> So, if I'm not mistaken, those are all marking tasks which can be
> depended upon during memory reclaim and we do want to catch them all.

Up to a point yes, these are things that want to be reliable during
reclaim, but lacking memory reserves and usage bounds (which we
discussed last at lsf/mm) these are just wanna-be.

> PF_MEMALLOC shouldn't depend on something which require memory to be
> reclaimed to guarantee forward progress.

PF_MEMALLOC basically avoids reclaim for any memory allocation while its
set.

The thing is, even if your workqueue has WQ_MEM_RECLAIM set, it will not
hit the mayday button until you're completely full flat out of memory.
At which point you're probably boned anyway, because, as per the above,
all that code assumes there's _some_ memory to be had.

One solution is to always fail maybe_create_worker() when PF_MEMALLOC is
set, thus always hitting the mayday button.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1283416 — Re: [PATCH] workqueue: warn if memory reclaim tries to flush !WQ_MEM_RECLAIM workqueue

FromTejun Heo <tj@kernel.org>
Date2015-12-03 23:10 +0100
SubjectRe: [PATCH] workqueue: warn if memory reclaim tries to flush !WQ_MEM_RECLAIM workqueue
Message-ID<qBKeC-2ve-13@gated-at.bofh.it>
In reply to#1283364
Hello, Peter.

On Thu, Dec 03, 2015 at 10:09:11PM +0100, Peter Zijlstra wrote:
> On Thu, Dec 03, 2015 at 03:56:32PM -0500, Tejun Heo wrote:
> > So, if I'm not mistaken, those are all marking tasks which can be
> > depended upon during memory reclaim and we do want to catch them all.
> 
> Up to a point yes, these are things that want to be reliable during
> reclaim, but lacking memory reserves and usage bounds (which we
> discussed last at lsf/mm) these are just wanna-be.

Hmmm... even if buggy in that they can't guarantee forward-progress
even with access to the emergency pool, I think it makes sense to warn
them about creating an extra dependency which doesn't have access to
the emergency pool.

> > PF_MEMALLOC shouldn't depend on something which require memory to be
> > reclaimed to guarantee forward progress.
> 
> PF_MEMALLOC basically avoids reclaim for any memory allocation while its
> set.

So, the assumption is that they're already on the reclaim path and
thus shouldn't recurse into it again.

> The thing is, even if your workqueue has WQ_MEM_RECLAIM set, it will not
> hit the mayday button until you're completely full flat out of memory.

It's more trigger-happy than that.  It's timer based.  If new worker
can't be created for a certain amount of time for whatever reason,
it'll summon the rescuer.

> At which point you're probably boned anyway, because, as per the above,
> all that code assumes there's _some_ memory to be had.

Not really.  PF_MEMALLOC tasks have access to the emergency pool,
creating new workers doesn't, so this really is creating a dependency
which is qualitatively different.

> One solution is to always fail maybe_create_worker() when PF_MEMALLOC is
> set, thus always hitting the mayday button.

I'm not following.  When PF_MEMALLOC is set where?

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1283792 — Re: [PATCH] workqueue: warn if memory reclaim tries to flush !WQ_MEM_RECLAIM workqueue

FromPeter Zijlstra <peterz@infradead.org>
Date2015-12-04 14:00 +0100
SubjectRe: [PATCH] workqueue: warn if memory reclaim tries to flush !WQ_MEM_RECLAIM workqueue
Message-ID<qBY7T-2M0-1@gated-at.bofh.it>
In reply to#1283416
On Thu, Dec 03, 2015 at 05:04:06PM -0500, Tejun Heo wrote:
> > One solution is to always fail maybe_create_worker() when PF_MEMALLOC is
> > set, thus always hitting the mayday button.
> 
> I'm not following.  When PF_MEMALLOC is set where?

It seems I made a false assumption. I was thinking the worker creation
was done from queue/flush context, but its done by other workers, at a
time when PF_MEMALLOC cannot be set.

In any case, no objections to the proposed patch.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1285684 — Re: [PATCH] workqueue: warn if memory reclaim tries to flush !WQ_MEM_RECLAIM workqueue

FromTejun Heo <tj@kernel.org>
Date2015-12-07 17:00 +0100
SubjectRe: [PATCH] workqueue: warn if memory reclaim tries to flush !WQ_MEM_RECLAIM workqueue
Message-ID<qD6mL-6tX-45@gated-at.bofh.it>
In reply to#1283274
On Thu, Dec 03, 2015 at 02:26:16PM -0500, Tejun Heo wrote:
> Task or work item involved in memory reclaim trying to flush a
> non-WQ_MEM_RECLAIM workqueue or one of its work items can lead to
> deadlock.  Trigger WARN_ONCE() if such conditions are detected.
> 
> Signed-off-by: Tejun Heo <tj@kernel.org>
> Cc: Peter Zijlstra <peterz@infradead.org>

Applied to wq/for-4.5.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1283110

FromPeter Zijlstra <peterz@infradead.org>
Date2015-12-03 16:10 +0100
Message-ID<qBDGa-6Nq-19@gated-at.bofh.it>
In reply to#1283096
On Thu, Dec 03, 2015 at 09:48:11AM -0500, Tejun Heo wrote:
> We can add MEM_RECLAIM -> !MEM_RECLAIM warning mechanism in addition
> but I think adding stall detection is justified.

Sure, a stall mech is always nice, but I was thinking we should be able
to better catch some of these with explicit stuff.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web