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


Groups > linux.kernel > #1734636 > unrolled thread

Re: [PATCH] mm, memory_hotplug: do not back off draining pcp free pages from kworker context

Started byTejun Heo <tj@kernel.org>
First post2017-09-19 05:40 +0200
Last post2017-09-19 21:00 +0200
Articles 3 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH] mm, memory_hotplug: do not back off draining pcp free  pages from kworker context Tejun Heo <tj@kernel.org> - 2017-09-19 05:40 +0200
    Re: [PATCH] mm, memory_hotplug: do not back off draining pcp free  pages from kworker context Michal Hocko <mhocko@kernel.org> - 2017-09-19 11:50 +0200
      Re: [PATCH] mm, memory_hotplug: do not back off draining pcp free  pages from kworker context Tejun Heo <tj@kernel.org> - 2017-09-19 21:00 +0200

#1734636 — Re: [PATCH] mm, memory_hotplug: do not back off draining pcp free pages from kworker context

FromTejun Heo <tj@kernel.org>
Date2017-09-19 05:40 +0200
SubjectRe: [PATCH] mm, memory_hotplug: do not back off draining pcp free pages from kworker context
Message-ID<urhyb-7dq-9@gated-at.bofh.it>
Hello, Sorry about the delay.

On Thu, Aug 31, 2017 at 07:33:42AM +0200, Michal Hocko wrote:
> > > Michal, are you sure that this patch does not cause deadlock?
> > > 
> > > As shown in "[PATCH] mm: Use WQ_HIGHPRI for mm_percpu_wq." thread, currently work
> > > items on mm_percpu_wq seem to be blocked by other work items not on mm_percpu_wq.

IIUC that wasn't a deadlock but more a legitimate starvation from too
many tasks trying to reclaim directly.

> > But we have a rescuer so we should make a forward progress eventually.
> > Or am I missing something. Tejun, could you have a look please?
> 
> ping... I would really appreaciate if you could double check my thinking
> Tejun. This is a tricky area and I would like to prevent further subtle
> issues here.

So, this shouldn't be an issue.  This may get affected by direct
reclaim frenzy but it's only a small piece of the whole symptom and we
gotta fix that at the source.

Thanks.

-- 
tejun

[toc] | [next] | [standalone]


#1734768

FromMichal Hocko <mhocko@kernel.org>
Date2017-09-19 11:50 +0200
Message-ID<urnkd-39c-3@gated-at.bofh.it>
In reply to#1734636
On Mon 18-09-17 20:38:22, Tejun Heo wrote:
> Hello, Sorry about the delay.
> 
> On Thu, Aug 31, 2017 at 07:33:42AM +0200, Michal Hocko wrote:
> > > > Michal, are you sure that this patch does not cause deadlock?
> > > > 
> > > > As shown in "[PATCH] mm: Use WQ_HIGHPRI for mm_percpu_wq." thread, currently work
> > > > items on mm_percpu_wq seem to be blocked by other work items not on mm_percpu_wq.
> 
> IIUC that wasn't a deadlock but more a legitimate starvation from too
> many tasks trying to reclaim directly.
> 
> > > But we have a rescuer so we should make a forward progress eventually.
> > > Or am I missing something. Tejun, could you have a look please?
> > 
> > ping... I would really appreaciate if you could double check my thinking
> > Tejun. This is a tricky area and I would like to prevent further subtle
> > issues here.
> 
> So, this shouldn't be an issue.  This may get affected by direct
> reclaim frenzy but it's only a small piece of the whole symptom and we
> gotta fix that at the source.

OK, so there shouldn't be any issue with the patch, right?
-- 
Michal Hocko
SUSE Labs

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


#1735176

FromTejun Heo <tj@kernel.org>
Date2017-09-19 21:00 +0200
Message-ID<urvUu-AH-11@gated-at.bofh.it>
In reply to#1734768
Hello,

On Tue, Sep 19, 2017 at 11:45:21AM +0200, Michal Hocko wrote:
> > So, this shouldn't be an issue.  This may get affected by direct
> > reclaim frenzy but it's only a small piece of the whole symptom and we
> > gotta fix that at the source.
> 
> OK, so there shouldn't be any issue with the patch, right?

idk, it'll make the code path more susceptible to direct reclaim
starvations, so it's difficult to claim that there won't be *any*
problems; however, given the extent of the starvation problem, this
likely won't add any noticeable issues.

Thanks.

-- 
tejun

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web