On 2015-02-28 11:43, Tejun Heo wrote:
Hello, Tim.
On Sat, Feb 28, 2015 at 08:38:07AM -0800, Tim Hockin wrote:
I know there is not much concern for legacy-system problems, but it is
worth adding this case - there are systems that limit PIDs for other
reasons, eg broken infrastructure that assumes PIDs fit in a short int,
hypothetically. Given such a system, PIDs become precious and limiting
them per job is important.
My main point being that there are less obvious considerations in play than
just memory usage.
Sure, there are those cases but it'd be unwise to hinge long term
decisions on them. It's hard to even argue 16bit pid in legacy code
as a significant contributing factor at this point. At any rate, it
seems that pid is a global resource which needs to be provisioned for
reasonable isolation which is a good reason to consider controlling it
via cgroups.
If 16-bit PID's aren't a concern anymore, then why do we still default
to treating it like a 16-bit signed int (the default for
/proc/sys/kernel/pid_max is 32768)?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
