All of lore.kernel.org
 help / color / mirror / Atom feed
From: Niv Yehezkel <executerx@gmail.com>
To: Michal Hocko <mhocko@suse.cz>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org,
	rientjes@google.com, hannes@cmpxchg.org, oleg@redhat.com
Subject: Re: [PATCH] oom: break after selecting process to kill
Date: Fri, 12 Sep 2014 04:23:29 -0400	[thread overview]
Message-ID: <20140912082329.GA12330@localhost.localdomain> (raw)
In-Reply-To: <20140912080853.GA12156@dhcp22.suse.cz>

[-- Attachment #1: Type: text/plain, Size: 3012 bytes --]

On Fri, Sep 12, 2014 at 10:08:53AM +0200, Michal Hocko wrote:
> On Thu 11-09-14 17:33:39, Niv Yehezkel wrote:
> > There is no need to fallback and continue computing
> > badness for each running process after we have found a
> > process currently performing the swapoff syscall. We ought to
> > immediately select this process for killing.
> 
> a) this is not only about swapoff. KSM (run_store) is currently
>    considered oom origin as well.
> b) you forgot to tell us what led you to this change. It sounds like a
>    minor optimization to me. We can potentially skip scanning through
>    many tasks but this is not guaranteed at all because our task might
>    be at the very end of the tasks list as well.
> c) finally this might select thread != thread_group_leader which is a
>    minor issue affecting oom report
> 
> I am not saying the change is wrong but please make sure you first
> describe your motivation. Does it fix any issue you are seeing?  Is this
> just something that struck you while reading the code? Maybe it was 
> /* always select this thread first */ comment for OOM_SCAN_SELECT.
> Besides that your process_selected is not really needed. You could test
> for chosen_points == ULONG_MAX as well. This would be even more
> straightforward because any score like that is ultimate candidate.
> 
> > Signed-off-by: Niv Yehezkel <executerx@gmail.com>
> > ---
> >  mm/oom_kill.c |    6 +++++-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> > 
> > diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> > index 1e11df8..68ac30e 100644
> > --- a/mm/oom_kill.c
> > +++ b/mm/oom_kill.c
> > @@ -305,6 +305,7 @@ static struct task_struct *select_bad_process(unsigned int *ppoints,
> >  	struct task_struct *g, *p;
> >  	struct task_struct *chosen = NULL;
> >  	unsigned long chosen_points = 0;
> > +	bool process_selected = false;
> >  
> >  	rcu_read_lock();
> >  	for_each_process_thread(g, p) {
> > @@ -315,7 +316,8 @@ static struct task_struct *select_bad_process(unsigned int *ppoints,
> >  		case OOM_SCAN_SELECT:
> >  			chosen = p;
> >  			chosen_points = ULONG_MAX;
> > -			/* fall through */
> > +			process_selected = true;
> > +			break;
> >  		case OOM_SCAN_CONTINUE:
> >  			continue;
> >  		case OOM_SCAN_ABORT:
> > @@ -324,6 +326,8 @@ static struct task_struct *select_bad_process(unsigned int *ppoints,
> >  		case OOM_SCAN_OK:
> >  			break;
> >  		};
> > +		if (process_selected)
> > +			break;
> >  		points = oom_badness(p, NULL, nodemask, totalpages);
> >  		if (!points || points < chosen_points)
> >  			continue;
> > -- 
> > 1.7.10.4
> > 
> 
> -- 
> Michal Hocko
> SUSE Labs

Been reviewing kernel code lately and looking for implementations not fulfilling their actual intention. That's about most of the patches I tend to send.
Motivation is pretty much derived from the Eudyptula challenge so there is not concrete reason for this patch.

To the point: I have not witnessed any major affects to performance due to this.
I fixed the patch and attached it to this mail.

[-- Attachment #2: 0001-break-after-selecting-process-to-kill.patch --]
[-- Type: text/x-diff, Size: 0 bytes --]



  reply	other threads:[~2014-09-12  8:23 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-11 21:33 [PATCH] oom: break after selecting process to kill Niv Yehezkel
2014-09-12  1:22 ` Zhang Zhen
2014-09-12  7:39   ` Niv Yehezkel
2014-09-12  8:08 ` Michal Hocko
2014-09-12  8:23   ` Niv Yehezkel [this message]
2014-09-12 12:18     ` Michal Hocko
2014-09-12 12:21       ` Niv Yehezkel
2014-09-12 12:31         ` Michal Hocko
2014-09-14 20:46         ` David Rientjes
2014-09-23 18:30           ` Michal Hocko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140912082329.GA12330@localhost.localdomain \
    --to=executerx@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.cz \
    --cc=oleg@redhat.com \
    --cc=rientjes@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.