[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100422135742.GQ4920@sgi.com>
Date: Thu, 22 Apr 2010 08:57:42 -0500
From: Robin Holt <holt@....com>
To: Alan Cox <alan@...rguk.ukuu.org.uk>
Cc: Greg KH <gregkh@...e.de>, Rik van Riel <riel@...hat.com>,
John Stoffel <john@...ffel.org>, Hedi Berriche <hedi@....com>,
Mike Travis <travis@....com>, Ingo Molnar <mingo@...e.hu>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Jack Steiner <steiner@....com>,
Andrew Morton <akpm@...ux-foundation.org>,
Robin Holt <holt@....com>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [Patch 1/1] init: Provide a kernel start parameter to increase
pid_max v2
> No - to start with it would be far saner for everything involved if the
> 4096 processor minority fixed it for the moment in their arch code by
> doing something like
>
> if (max_pids < PIDS_PER_CPU * num_cpus) {
> max_pids = ...
> printk(something informative)
> }
>
> in their __init marked code.
I don't understand how it would be possible for the arch maintainers
to predict what a particular machine's configuration would need for
PIDS_PER_CPU. Many of the extra pids needed on a per-cpu basis are
brought in by device drivers or subsystems.
Are you proposing a typical configuration be used for the basis or an
extreme configuration?
If your basis is the typical configuration, how would an administrator
of the extreme configuration get themselves out of the situation of
pids_max being too small without the same command line option.
If we use the extreme case, then we end up with a lot of extraneous pids,
however I don't see that as being too terrible of a situation.
Robin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists