With the full changelog and the vmstat update for the reference.
---
>From 9492966a552751e6d7a63e9aafb87e35992b840a Mon Sep 17 00:00:00 2001
From: Michal Hocko
Date: Wed, 11 Nov 2015 16:45:53 +0100
Subject: [PATCH] mm, vmstat: Allow WQ concurrency to discover memory reclaim
doesn't make any progr
On Thu 05-11-15 19:16:48, Tejun Heo wrote:
> Hello,
>
> On Thu, Nov 05, 2015 at 11:45:42AM -0600, Christoph Lameter wrote:
> > Sorry but we need work queue processing for vmstat counters that is
>
> I made this analogy before but this is similar to looping with
> preemption off. If anything on w
Hello,
On Thu, Nov 05, 2015 at 11:45:42AM -0600, Christoph Lameter wrote:
> Sorry but we need work queue processing for vmstat counters that is
I made this analogy before but this is similar to looping with
preemption off. If anything on workqueue stays RUNNING w/o making
forward progress, it's
On Thu, 5 Nov 2015, Tetsuo Handa wrote:
> memory allocation. By allowing workqueue items to be processed (by using
> short sleep), some task might release memory when workqueue item is
> processed.
>
> Therefore, not only to keep vmstat counters up to date, but also for
> avoid wasting CPU cycles,
Michal Hocko wrote:
> As already pointed out I really detest a short sleep and would prefer
> a way to tell WQ what we really need. vmstat is not the only user. OOM
> sysrq will need this special treatment as well. While the
> zone_reclaimable can be fixed in an easy patch
> (http://lkml.kernel.org
Hello, Tetsuo.
On Tue, Nov 03, 2015 at 11:32:06AM +0900, Tetsuo Handa wrote:
> Tejun Heo wrote:
> > If
> > the possibility of sysrq getting stuck behind concurrency management
> > is an issue, queueing them on an unbound or highpri w
Tejun Heo wrote:
> If
> the possibility of sysrq getting stuck behind concurrency management
> is an issue, queueing them on an unbound or highpri workqueue should
> be good enough.
Regarding SysRq-f, we could do like below. Though I
On Mon, Nov 02, 2015 at 04:01:37PM +0100, Michal Hocko wrote:
...
> which is perfectly suited for the stable backport, OOM sysrq resp. any
> sysrq which runs from the WQ context should be as robust as possible and
> shouldn't rely on all the code running from WQ context to issue a sleep
> to get un
On Fri 23-10-15 13:26:49, Tejun Heo wrote:
> Hello,
>
> So, something like the following. Just compile tested but this is
> essentially partial revert of 3270476a6c0c ("workqueue: reimplement
> WQ_HIGHPRI using a separate worker_pool") - resurrecting the old
> WQ_HIGHPRI implementation under WQ_I
On Tue 27-10-15 19:55:06, Tejun Heo wrote:
> On Tue, Oct 27, 2015 at 10:22:31AM +0100, Michal Hocko wrote:
> ...
> > stable kernels without causing any other regressions. 2) is the way
> > to move forward for next kernels and we should really think whether
> > WQ_MEM_RECLAIM should imply also WQ_HI
On Tue, Oct 27, 2015 at 08:07:38PM +0900, Tetsuo Handa wrote:
> Can't we have a waitqueue like
> http://lkml.kernel.org/r/201510142121.ide86954.sovoffqofmj...@i-love.sakura.ne.jp
> ?
There's no reason to complicate it. It wouldn't buy anything
meaningful. Can we please stop trying to solve a no
Michal Hocko wrote:
> > On Fri, Oct 23, 2015 at 01:11:45PM +0200, Michal Hocko wrote:
> > > > The problem here is not lack
> > > > of execution resource but concurrency management misunderstanding the
> > > > situation.
> > >
> > > And this sounds like a bug to me.
> >
> > I don't know. I can b
On Tue, Oct 27, 2015 at 10:22:31AM +0100, Michal Hocko wrote:
...
> stable kernels without causing any other regressions. 2) is the way
> to move forward for next kernels and we should really think whether
> WQ_MEM_RECLAIM should imply also WQ_HIGHPRI by default. If there is a
> general consensus t
Hello, Michal.
On Tue, Oct 27, 2015 at 10:16:03AM +0100, Michal Hocko wrote:
> > Seriously, nobody goes full-on RUNNING.
>
> Looping with cond_resched seems like general pattern in the kernel when
> there is no clear source to wait for. We have io_schedule when we know
> we should wait for IO (in
On Sun 25-10-15 19:52:59, Tetsuo Handa wrote:
[...]
> Three approaches are proposed for fixing this silent livelock problem.
>
> (1) Use zone_page_state_snapshot() instead of zone_page_state()
> when doing zone_reclaimable() checks. This approach is clear,
> straightforward and easy to
On Sat 24-10-15 03:21:09, Tejun Heo wrote:
> Hello,
>
> On Fri, Oct 23, 2015 at 01:11:45PM +0200, Michal Hocko wrote:
> > > The problem here is not lack
> > > of execution resource but concurrency management misunderstanding the
> > > situation.
> >
> > And this sounds like a bug to me.
>
> I d
Hello,
On Sun, Oct 25, 2015 at 07:52:59PM +0900, Tetsuo Handa wrote:
...
> This means that any kernel code which invokes a __GFP_WAIT allocation
> might fail to do (4) when invoked via workqueue, regardless of flags
> passed to alloc_workqueue()?
Sounds that way and yeah (3) should technically be
Tejun Heo wrote:
> If this is an actual problem, a better approach would be something
> which detects the stall condition and kicks off the next work item but
> if we do that I think I'd still trigger a warning there. I don't
> know. Don't go busy waiting in kernel.
Busy waiting in kernel refers
Hello, Tetsuo.
On Fri, Oct 23, 2015 at 09:25:11PM +0900, Tetsuo Handa wrote:
> WQ_MEM_RECLAIM only guarantees that a "struct task_struct" is preallocated
> in order to avoid failing to allocate it on demand due to a GFP_KERNEL
> allocation? Is this correct?
>
> WQ_CPU_INTENSIVE only guarantees th
Hello,
On Fri, Oct 23, 2015 at 01:11:45PM +0200, Michal Hocko wrote:
> > The problem here is not lack
> > of execution resource but concurrency management misunderstanding the
> > situation.
>
> And this sounds like a bug to me.
I don't know. I can be argued either way, the other direction bei
On Fri, 23 Oct 2015, Sergey Senozhatsky wrote:
> by the way, tick_nohz_stop_sched_tick() receives cpu from
> __tick_nohz_idle_enter().
> do you want to pass it to quiet_vmstat()?
No this is quite wrong at this point. quiet_vmstat() needs to be called
from the cpu going into idle state.
--
To uns
On (10/23/15 09:12), Christoph Lameter wrote:
[..]
> > > + if (!cpumask_test_and_set_cpu(smp_processor_id(), cpu_stat_off))
> > > + cancel_delayed_work(this_cpu_ptr(&vmstat_work));
> >
> > shouldn't preemption be disable for smp_processor_id() here?
>
> Preemption is disabl
On Fri, 23 Oct 2015, Sergey Senozhatsky wrote:
> On (10/23/15 06:43), Christoph Lameter wrote:
> > Is this ok?
>
> kernel/sched/loadavg.c: In function ‘calc_load_enter_idle’:
> kernel/sched/loadavg.c:195:2: error: implicit declaration of function
> ‘quiet_vmstat’ [-Werror=implicit-function-declar
Michal Hocko wrote:
> On Fri 23-10-15 19:36:30, Tejun Heo wrote:
> > Hello, Michal.
> >
> > On Fri, Oct 23, 2015 at 10:33:16AM +0200, Michal Hocko wrote:
> > > Ohh, OK I can see wq_worker_sleeping now. I've missed your point in
> > > other email, sorry about that. But now I am wondering whether th
On (10/23/15 06:43), Christoph Lameter wrote:
> Is this ok?
kernel/sched/loadavg.c: In function ‘calc_load_enter_idle’:
kernel/sched/loadavg.c:195:2: error: implicit declaration of function
‘quiet_vmstat’ [-Werror=implicit-function-declaration]
quiet_vmstat();
^
> Subject: Fix vmstat: make
On Fri, 23 Oct 2015, Michal Hocko wrote:
> On Thu 22-10-15 10:33:20, Christoph Lameter wrote:
> > Ok that also makes me rethink commit
> > ba4877b9ca51f80b5d30f304a46762f0509e1635 which seems to be a similar fix
> > this time related to idle mode not updating the counters.
> >
> > Could we fix tha
On Fri 23-10-15 19:36:30, Tejun Heo wrote:
> Hello, Michal.
>
> On Fri, Oct 23, 2015 at 10:33:16AM +0200, Michal Hocko wrote:
> > Ohh, OK I can see wq_worker_sleeping now. I've missed your point in
> > other email, sorry about that. But now I am wondering whether this
> > is an intended behavior.
On Fri, Oct 23, 2015 at 10:36:12AM +0200, Michal Hocko wrote:
> If WQ_MEM_RECLAIM can really guarantee one worker as described in the
> documentation then I agree that fixing vmstat is a better fix. But that
> doesn't seem to be the case currently.
It does.
--
tejun
--
To unsubscribe from this l
Hello, Michal.
On Fri, Oct 23, 2015 at 10:33:16AM +0200, Michal Hocko wrote:
> Ohh, OK I can see wq_worker_sleeping now. I've missed your point in
> other email, sorry about that. But now I am wondering whether this
> is an intended behavior. The documentation says:
This is.
> WQ_MEM_RECLAIM
>
On Thu 22-10-15 10:33:20, Christoph Lameter wrote:
> Ok that also makes me rethink commit
> ba4877b9ca51f80b5d30f304a46762f0509e1635 which seems to be a similar fix
> this time related to idle mode not updating the counters.
>
> Could we fix that by folding the counters before going to idle mode?
On Fri 23-10-15 06:42:43, Tetsuo Handa wrote:
> Tejun Heo wrote:
> > On Thu, Oct 22, 2015 at 05:49:22PM +0200, Michal Hocko wrote:
> > > I am confused. What makes rescuer to not run? Nothing seems to be
> > > hogging CPUs, we are just out of workers which are loopin in the
> > > allocator but that
On Fri 23-10-15 03:42:26, Tejun Heo wrote:
> On Thu, Oct 22, 2015 at 05:49:22PM +0200, Michal Hocko wrote:
> > I am confused. What makes rescuer to not run? Nothing seems to be
> > hogging CPUs, we are just out of workers which are loopin in the
> > allocator but that is preemptible context.
>
> I
Hello,
So, something like the following. Just compile tested but this is
essentially partial revert of 3270476a6c0c ("workqueue: reimplement
WQ_HIGHPRI using a separate worker_pool") - resurrecting the old
WQ_HIGHPRI implementation under WQ_IMMEDIATE, so we know this works.
If for some reason, it
Hello,
On Fri, Oct 23, 2015 at 06:42:43AM +0900, Tetsuo Handa wrote:
> Then, isn't below change easier to backport which will also alleviate
> needlessly burning CPU cycles?
>
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -3385,6 +3385,7 @@ retry:
> ((gfp_mask & __GFP_REPEAT) && page
Tejun Heo wrote:
> On Thu, Oct 22, 2015 at 05:49:22PM +0200, Michal Hocko wrote:
> > I am confused. What makes rescuer to not run? Nothing seems to be
> > hogging CPUs, we are just out of workers which are loopin in the
> > allocator but that is preemptible context.
>
> It's concurrency management
On Thu, Oct 22, 2015 at 05:49:22PM +0200, Michal Hocko wrote:
> I am confused. What makes rescuer to not run? Nothing seems to be
> hogging CPUs, we are just out of workers which are loopin in the
> allocator but that is preemptible context.
It's concurrency management. Workqueue thinks that the
On Fri 23-10-15 00:37:03, Tejun Heo wrote:
> On Thu, Oct 22, 2015 at 05:35:59PM +0200, Michal Hocko wrote:
> > But that shouldn't happen because the allocation path does cond_resched
> > even when nothing is really reclaimable (e.g. wait_iff_congested from
> > __alloc_pages_slowpath).
>
> cond_res
On Thu, Oct 22, 2015 at 05:35:59PM +0200, Michal Hocko wrote:
> But that shouldn't happen because the allocation path does cond_resched
> even when nothing is really reclaimable (e.g. wait_iff_congested from
> __alloc_pages_slowpath).
cond_resched() isn't enough. The work item should go !RUNNING,
On Fri 23-10-15 00:15:28, Tejun Heo wrote:
> On Thu, Oct 22, 2015 at 05:06:23PM +0200, Michal Hocko wrote:
> > Do I get it right that if vmstat_update has its own workqueue with
> > WQ_MEM_RECLAIM then there is a _guarantee_ that the rescuer will always
> > be able to process vmstat_update work fro
Ok that also makes me rethink commit
ba4877b9ca51f80b5d30f304a46762f0509e1635 which seems to be a similar fix
this time related to idle mode not updating the counters.
Could we fix that by folding the counters before going to idle mode?
That fix seems to now create 2 separate application interupt
Hello,
On Thu, Oct 22, 2015 at 09:41:11AM -0500, Christoph Lameter wrote:
> > If this is actually a legit busy-waiting cyclic dependency, just let
> > me know.
>
> There is no dependency of the vmstat updater on anything.
> They can run anytime. If there is a dependency then its created by the
>
On Thu, Oct 22, 2015 at 05:06:23PM +0200, Michal Hocko wrote:
> Do I get it right that if vmstat_update has its own workqueue with
> WQ_MEM_RECLAIM then there is a _guarantee_ that the rescuer will always
> be able to process vmstat_update work from the requested CPU?
Yeah.
> That should be suffi
On Thu 22-10-15 23:09:44, Tejun Heo wrote:
> On Thu, Oct 22, 2015 at 08:39:11AM -0500, Christoph Lameter wrote:
> > On Thu, 22 Oct 2015, Tetsuo Handa wrote:
> >
> > > The problem would be that the "struct task_struct" to execute
> > > vmstat_update
> > > job does not exist, and will not be able t
On Thu, 22 Oct 2015, Tejun Heo wrote:
> The only way to hang the execution for a work item w/ WQ_MEM_RECLAIM
> is to create a cyclic dependency on another work item and keep that
> work item busy wait. Workqueue thinks that work item is making
> progress as it's running and doesn't schedule the n
On Thu, Oct 22, 2015 at 09:25:49AM -0500, Christoph Lameter wrote:
> On Thu, 22 Oct 2015, Tejun Heo wrote:
>
> > On Thu, Oct 22, 2015 at 09:23:54AM -0500, Christoph Lameter wrote:
> > > I guess we need that otherwise vm statistics are not updated while worker
> > > threads are blocking on memory r
On Thu, 22 Oct 2015, Tejun Heo wrote:
> On Thu, Oct 22, 2015 at 09:23:54AM -0500, Christoph Lameter wrote:
> > I guess we need that otherwise vm statistics are not updated while worker
> > threads are blocking on memory reclaim.
>
> And the blocking one is just constantly running?
I was told that
On Thu, Oct 22, 2015 at 09:23:54AM -0500, Christoph Lameter wrote:
> I guess we need that otherwise vm statistics are not updated while worker
> threads are blocking on memory reclaim.
And the blocking one is just constantly running?
--
tejun
--
To unsubscribe from this list: send the line "unsu
On Thu, 22 Oct 2015, Tejun Heo wrote:
> > Hmmm? Just use a dedicated workqueue with WQ_MEM_RECLAIM. If
> > concurrency management is a problem and there's something live-locking
> > for that work item (really?), WQ_CPU_INTENSIVE escapes it. If this is
> > a common occurrence that it makes sense
On Thu, 22 Oct 2015, Tejun Heo wrote:
> > Yuck. Can someone please get this major screwup out of the work queue
> > subsystem? Tejun?
>
> Hmmm? Just use a dedicated workqueue with WQ_MEM_RECLAIM. If
> concurrency management is a problem and there's something live-locking
> for that work item (re
On Thu, Oct 22, 2015 at 11:09:44PM +0900, Tejun Heo wrote:
> On Thu, Oct 22, 2015 at 08:39:11AM -0500, Christoph Lameter wrote:
> > On Thu, 22 Oct 2015, Tetsuo Handa wrote:
> >
> > > The problem would be that the "struct task_struct" to execute
> > > vmstat_update
> > > job does not exist, and wi
On Thu, Oct 22, 2015 at 08:39:11AM -0500, Christoph Lameter wrote:
> On Thu, 22 Oct 2015, Tetsuo Handa wrote:
>
> > The problem would be that the "struct task_struct" to execute vmstat_update
> > job does not exist, and will not be able to create one on demand because we
> > are stuck at __GFP_WAI
On Thu, 22 Oct 2015, Tetsuo Handa wrote:
> The problem would be that the "struct task_struct" to execute vmstat_update
> job does not exist, and will not be able to create one on demand because we
> are stuck at __GFP_WAIT allocation. Therefore adding a dedicated kernel
> thread for vmstat_update
Christoph Lameter wrote:
> On Wed, 21 Oct 2015, Michal Hocko wrote:
>
> > I am not sure how to achieve that. Requiring non-sleeping worker would
> > work out but do we have enough users to add such an API?
> >
> > I would rather see vmstat using dedicated kernel thread(s) for this this
> > purpose
On Wed, 21 Oct 2015, Michal Hocko wrote:
> I am not sure how to achieve that. Requiring non-sleeping worker would
> work out but do we have enough users to add such an API?
>
> I would rather see vmstat using dedicated kernel thread(s) for this this
> purpose. We have discussed that in the past bu
Michal Hocko wrote:
> On Wed 21-10-15 09:49:07, Christoph Lameter wrote:
> > On Wed, 21 Oct 2015, Michal Hocko wrote:
> >
> > > Because all the WQ workers are stuck somewhere, maybe in the memory
> > > allocation which cannot make any progress and the vmstat update work is
> > > queued behind them
On Wed 21-10-15 09:49:07, Christoph Lameter wrote:
> On Wed, 21 Oct 2015, Michal Hocko wrote:
>
> > Because all the WQ workers are stuck somewhere, maybe in the memory
> > allocation which cannot make any progress and the vmstat update work is
> > queued behind them.
> >
> > At least this is my cu
On Wed, 21 Oct 2015, Michal Hocko wrote:
> Because all the WQ workers are stuck somewhere, maybe in the memory
> allocation which cannot make any progress and the vmstat update work is
> queued behind them.
>
> At least this is my current understanding.
Eww. Maybe need a queue that does not do su
On Wed 21-10-15 09:22:40, Christoph Lameter wrote:
> On Wed, 21 Oct 2015, Tetsuo Handa wrote:
>
> > However, if a workqueue which is processed before vmstat_update
> > workqueue is processed got stuck inside memory allocation request,
> > values in vm_stat_diff[] cannot be merged into vm_stat[]. A
On Wed, 21 Oct 2015, Tetsuo Handa wrote:
> However, if a workqueue which is processed before vmstat_update
> workqueue is processed got stuck inside memory allocation request,
> values in vm_stat_diff[] cannot be merged into vm_stat[]. As a result,
> zone_reclaimable() continues using outdated vm_
On Wed 21-10-15 21:26:19, Tetsuo Handa wrote:
> >From 0c50792dfa6396453c89c71351a7458b94d3e881 Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa
> Date: Wed, 21 Oct 2015 21:15:30 +0900
> Subject: [PATCH] mm,vmscan: Use accurate values for zone_reclaimable() checks
>
> Since &
>From 0c50792dfa6396453c89c71351a7458b94d3e881 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Wed, 21 Oct 2015 21:15:30 +0900
Subject: [PATCH] mm,vmscan: Use accurate values for zone_reclaimable() checks
Since "struct zone"->vm_stat[] is array of atomic_long_t, an attempt
to
61 matches
Mail list logo
