linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Andrew Morton <akpm@linux-foundation.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: threads-max observe limits
Date: Mon, 23 Sep 2019 10:08:08 +0200	[thread overview]
Message-ID: <20190923080808.GA6016@dhcp22.suse.cz> (raw)
In-Reply-To: <875zlk3tz9.fsf@x220.int.ebiederm.org>

Andrew, do you want me to send the patch or you can grab it from here?

On Sun 22-09-19 16:24:10, Eric W. Biederman wrote:
> Michal Hocko <mhocko@kernel.org> writes:
> 
> > From 711000fdc243b6bc68a92f9ef0017ae495086d39 Mon Sep 17 00:00:00 2001
> > From: Michal Hocko <mhocko@suse.com>
> > Date: Sun, 22 Sep 2019 08:45:28 +0200
> > Subject: [PATCH] kernel/sysctl.c: do not override max_threads provided by
> >  userspace
> >
> > Partially revert 16db3d3f1170 ("kernel/sysctl.c: threads-max observe limits")
> > because the patch is causing a regression to any workload which needs to
> > override the auto-tuning of the limit provided by kernel.
> >
> > set_max_threads is implementing a boot time guesstimate to provide a
> > sensible limit of the concurrently running threads so that runaways will
> > not deplete all the memory. This is a good thing in general but there
> > are workloads which might need to increase this limit for an application
> > to run (reportedly WebSpher MQ is affected) and that is simply not
> > possible after the mentioned change. It is also very dubious to override
> > an admin decision by an estimation that doesn't have any direct relation
> > to correctness of the kernel operation.
> >
> > Fix this by dropping set_max_threads from sysctl_max_threads so any
> > value is accepted as long as it fits into MAX_THREADS which is important
> > to check because allowing more threads could break internal robust futex
> > restriction. While at it, do not use MIN_THREADS as the lower boundary
> > because it is also only a heuristic for automatic estimation and admin
> > might have a good reason to stop new threads to be created even when
> > below this limit.
> >
> > Fixes: 16db3d3f1170 ("kernel/sysctl.c: threads-max observe limits")
> > Cc: stable
> > Signed-off-by: Michal Hocko <mhocko@suse.com>
> Reviewed-by: "Eric W. Biederman" <ebiederm@xmission.com>

Thanks Eric.

> > ---
> >  kernel/fork.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/kernel/fork.c b/kernel/fork.c
> > index 2852d0e76ea3..ef865be37e98 100644
> > --- a/kernel/fork.c
> > +++ b/kernel/fork.c
> > @@ -2929,7 +2929,7 @@ int sysctl_max_threads(struct ctl_table *table, int write,
> >  	struct ctl_table t;
> >  	int ret;
> >  	int threads = max_threads;
> > -	int min = MIN_THREADS;
> > +	int min = 1;
> >  	int max = MAX_THREADS;
> >  
> >  	t = *table;
> > @@ -2941,7 +2941,7 @@ int sysctl_max_threads(struct ctl_table *table, int write,
> >  	if (ret || !write)
> >  		return ret;
> >  
> > -	set_max_threads(threads);
> > +	max_threads = threads;
> >  
> >  	return 0;
> >  }
> > -- 
> > 2.20.1

-- 
Michal Hocko
SUSE Labs

  reply	other threads:[~2019-09-23  8:08 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-17 10:03 threads-max observe limits Michal Hocko
2019-09-17 15:28 ` Heinrich Schuchardt
2019-09-17 15:38   ` Michal Hocko
2019-09-17 17:26     ` Eric W. Biederman
2019-09-18  7:15       ` Michal Hocko
2019-09-19  7:59         ` Michal Hocko
2019-09-19 19:38           ` Andrew Morton
2019-09-19 19:33         ` Eric W. Biederman
2019-09-22  6:58           ` Michal Hocko
2019-09-22 15:31             ` Heinrich Schuchardt
2019-09-22 21:40               ` Eric W. Biederman
2019-09-22 21:24             ` Eric W. Biederman
2019-09-23  8:08               ` Michal Hocko [this message]
2019-09-23 21:23                 ` Eric W. Biederman
2019-09-24  8:48                   ` 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=20190923080808.GA6016@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=xypron.glpk@gmx.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).