All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Aaron Tomlin <atomlin@redhat.com>,
	Andy Lutomirski <luto@amacapital.net>,
	Davidlohr Bueso <dave@stgolabs.net>,
	David Rientjes <rientjes@google.com>,
	"David S. Miller" <davem@davemloft.net>,
	Fabian Frederick <fabf@skynet.be>,
	Guenter Roeck <linux@roeck-us.net>,
	"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@kernel.org>,
	Jens Axboe <axboe@fb.com>, Joe Perches <joe@perches.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Kees Cook <keescook@chromium.org>,
	Michael Marineau <mike@marineau.org>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Prarit Bhargava <prarit@redhat.com>,
	Rik van Riel <riel@redhat.com>,
	Rusty Russell <rusty@rustcorp.com.au>,
	Steven Rostedt <rostedt@goodmis.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Vladimir Davydov <vdavydov@parallels.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/4 v4] kernel/fork.c: memory hotplug updates max_threads
Date: Mon, 23 Feb 2015 22:46:35 +0100	[thread overview]
Message-ID: <20150223214635.GA29048@redhat.com> (raw)
In-Reply-To: <54EB9781.504@gmx.de>

On 02/23, Heinrich Schuchardt wrote:
>
> On 23.02.2015 21:54, Oleg Nesterov wrote:
> >
> >> And it changes the swapper/0's rlimits. This is pointless after we fork
> >> /sbin/init.
>
> So should writing to /proc/sys/max_threads update the limits of all
> processes?

Why?

No, I think it should not touch rlimits at all.

> >> It seems to me these patches need some cleanups. Plus I am not sure the
> >> kernel should update max_threads automatically, we have the "threads-max"
> >> sysctl.
>
> The idea in the original version of fork_init is that max_threads should
> be chosen such that the memory needed to store the meta-information of
> max_threads threads should only be 1/8th of the total memory.
>
> Somebody adding or removing memory will not necessarily update
> /proc/sys/kernel/threads-max.
>
> This means that if I remove 90 % of the memory I get to a situation
> where max_threads allows so many threads to be created that the
> meta-information occupies all memory.
>
> With patch 4/4 max_threads is automatically reduced in this case.

I understand. But I think that if you remove 90 % of the memory you can
also update /proc/sys/kernel/threads-max.

And, suppose that admin specially limited max_threads, then you add more
memory. Should the kernel bump the limit silently?

And if hotplug should update max_threads, why it doesn't update, say,
files_stat.max_files?

IOW, I do not think that kernel should control max_threads after boot.
But I won't really argue. Just this looks a bit strange to me.

Oleg.


  reply	other threads:[~2015-02-23 21:49 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-17 19:01 [PATCH 1/1 v2] kernel/fork.c: avoid division by zero Heinrich Schuchardt
2015-02-17 23:15 ` Andrew Morton
2015-02-18 19:38   ` Guenter Roeck
2015-02-18 19:50     ` Heinrich Schuchardt
2015-02-18 20:23       ` Guenter Roeck
2015-02-18 19:47   ` Heinrich Schuchardt
2015-02-18 20:28     ` Andrew Morton
2015-02-21 22:19       ` [PATCH 0/3 v3] kernel/fork.c max_thread handling Heinrich Schuchardt
2015-02-21 22:19         ` [PATCH 1/3 v3] kernel/fork.c: avoid division by zero Heinrich Schuchardt
2015-02-22  7:58           ` Ingo Molnar
2015-02-23 20:14             ` [PATCH 0/4 v4] max_threadx handling Heinrich Schuchardt
2015-02-23 20:14               ` [PATCH 1/4 v4] kernel/fork.c: new function for max_threads Heinrich Schuchardt
2015-02-23 20:14               ` [PATCH 2/4 v4] kernel/fork.c: avoid division by zero Heinrich Schuchardt
2015-02-23 21:10                 ` Peter Zijlstra
2015-02-23 21:29                   ` Heinrich Schuchardt
2015-02-24  7:35                 ` Ingo Molnar
2015-02-23 20:14               ` [PATCH 3/4 v4] kernel/sysctl.c: threads-max observe limits Heinrich Schuchardt
2015-02-23 20:14               ` [PATCH 4/4 v4] kernel/fork.c: memory hotplug updates max_threads Heinrich Schuchardt
2015-02-23 20:50                 ` Oleg Nesterov
2015-02-23 20:54                   ` Oleg Nesterov
2015-02-23 21:11                     ` Heinrich Schuchardt
2015-02-23 21:46                       ` Oleg Nesterov [this message]
2015-02-24 19:38               ` [PATCH 0/3 v5] max_threadx handling Heinrich Schuchardt
2015-02-24 19:38                 ` [PATCH 1/3 v5] kernel/fork.c: new function for max_threads Heinrich Schuchardt
2015-02-24 21:03                   ` David Rientjes
2015-02-24 21:23                     ` Heinrich Schuchardt
2015-02-24 22:16                       ` David Rientjes
2015-02-25  7:21                         ` Heinrich Schuchardt
2015-02-25 10:17                         ` Ingo Molnar
2015-02-25 19:08                           ` Heinrich Schuchardt
2015-02-25 21:07                             ` David Rientjes
2015-02-24 19:38                 ` [PATCH 2/3 v5] kernel/fork.c: avoid division by zero Heinrich Schuchardt
2015-02-24 21:14                   ` David Rientjes
2015-02-24 19:38                 ` [PATCH 3/3] kernel/sysctl.c: threads-max observe limits Heinrich Schuchardt
2015-02-24 21:17                   ` David Rientjes
2015-02-24 21:31                     ` Heinrich Schuchardt
2015-02-24 22:20                       ` David Rientjes
2015-02-25 18:47                         ` Heinrich Schuchardt
2015-02-25 20:47                           ` David Rientjes
2015-02-21 22:19         ` [PATCH 2/3 v3] " Heinrich Schuchardt
2015-02-21 22:19         ` [PATCH 3/3 v3] kernel/fork.c: memory hotplug updates max_threads Heinrich Schuchardt

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=20150223214635.GA29048@redhat.com \
    --to=oleg@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=atomlin@redhat.com \
    --cc=axboe@fb.com \
    --cc=dave@stgolabs.net \
    --cc=davem@davemloft.net \
    --cc=fabf@skynet.be \
    --cc=hannes@cmpxchg.org \
    --cc=hpa@zytor.com \
    --cc=joe@perches.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=luto@amacapital.net \
    --cc=mike@marineau.org \
    --cc=mingo@kernel.org \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=prarit@redhat.com \
    --cc=riel@redhat.com \
    --cc=rientjes@google.com \
    --cc=rostedt@goodmis.org \
    --cc=rusty@rustcorp.com.au \
    --cc=tglx@linutronix.de \
    --cc=vdavydov@parallels.com \
    --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 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.