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 21:54:12 +0100 [thread overview]
Message-ID: <20150223205412.GB26955@redhat.com> (raw)
In-Reply-To: <20150223205052.GA26955@redhat.com>
On 02/23, Oleg Nesterov wrote:
>
> On 02/23, Heinrich Schuchardt wrote:
> >
> > +static int memory_hotplug_callback(struct notifier_block *self,
> > + unsigned long action, void *arg)
> > +{
> > + switch (action) {
> > + case MEM_ONLINE:
> > + /*
> > + * If memory was added, try to maximize the number of allowed
> > + * threads.
> > + */
> > + set_max_threads(UINT_MAX);
> > + break;
> > + case MEM_OFFLINE:
> > + /*
> > + * If memory was removed, try to keep current value.
> > + */
> > + set_max_threads(max_threads);
> > + break;
> > + }
>
> can't understand... set_max_threads() added by 1/4 ignore its argument.
> Why does it need "int max_threads_suggested" then?
OOPS sorry, missed 2/4 ;)
> And it changes the swapper/0's rlimits. This is pointless after we fork
> /sbin/init.
>
> 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.
still true, or I am tottaly confused.
Oleg.
next prev parent reply other threads:[~2015-02-23 20:57 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 [this message]
2015-02-23 21:11 ` Heinrich Schuchardt
2015-02-23 21:46 ` Oleg Nesterov
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=20150223205412.GB26955@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.