|
|
|
|
| Re: [Containers] Q: Do systems using containers user more process ids? [message #5138 is a reply to message #5136] |
Mon, 14 August 2006 21:18   |
Dave Hansen
Messages: 240
Registered: October 2005
|
Senior Member |
|
|
On Mon, 2006-08-14 at 15:01 -0600, Eric W. Biederman wrote:
> The practical question is if systems using containers are using noticeably
> more pids than anyone else. So far the responses I have gotten indicate
> that users aren't. So at least until we descend into multi-core madness
> it sounds like the current structures are fine, but it might be worth moving
> the cap on the number of pid hash table entries at some point in the future.
Since it is already resized at boot-time, I can't imagine this be a real
problem to fix. I assume you're just trying to see if anybody has run
into it as of yet.
Perhaps a one-time-per-boot warning in find_pid() if the chains get too
long would be nice to have. It wouldn't give us detailed performance
measurements, but it would be a nice canary in the mine in case
something goes horribly wrong.
What about something like this?
---
lxc-dave/kernel/pid.c | 9 +++++++++
1 files changed, 9 insertions(+)
diff -puN Makefile~warn-on-long-pidhash-chains Makefile
diff -puN kernel/pid.c~warn-on-long-pidhash-chains kernel/pid.c
--- lxc/kernel/pid.c~warn-on-long-pidhash-chains 2006-08-14 14:13:39.000000000 -0700
+++ lxc-dave/kernel/pid.c 2006-08-14 14:17:49.000000000 -0700
@@ -209,9 +209,18 @@ struct pid * fastcall find_pid(int nr)
{
struct hlist_node *elem;
struct pid *pid;
+ int chain_length = 0;
+ static int chain_length_limit = 5;
+ static int issued_warning = 0;
hlist_for_each_entry_rcu(pid, elem,
&pid_hash[pid_hashfn(nr)], pid_chain) {
+ if (!issued_warning && (chain_length++ > chain_length_limit)) {
+ issued_warning = 1;
+ printk(KERN_WARN "%s() pid hash chain length "
+ "exceeded %d elements\n",
+ __FUNCTION__, chain_length);
+ }
WARN_ON(!pid->nr); /* to be removed soon */
if (pid->nr == nr)
return pid;
_
-- Dave
|
|
|
|
|
|
|
|
|
|
| Re: Q: Do systems using containers user more process ids? [message #5157 is a reply to message #5141] |
Tue, 15 August 2006 18:32 |
ebiederm
Messages: 1354
Registered: February 2006
|
Senior Member |
|
|
Kirill Korotaev <dev@sw.ru> writes:
>>>We have not seen any degradation here in real cases,
>>>but probably you are right and pid hash can be allocated taking into account
>>>physical memory as it is done for TCP/ip/other hashes?
>>
>>
>> It is but it is currently capped at 4K entries.
>> With 4K entries and 32K pids our worst case is usage is a hash chain
>> 9 entries long. At 4M pids our hash chains are 1000 entries long, which
>> sucks.
> 4M pids are almost unreal in production systems.
> (only if you spawn these tasks to make them sleep forever :))) ).
> we usually have no more than 20,000 tasks (which is 200VEs with 100 tasks in
> each)
Ok. That is a reasonable upper bound. I need to look and see what a heavily
loaded sever looks like.
>> The practical question is if systems using containers are using noticeably
>> more pids than anyone else. So far the responses I have gotten indicate
>> that users aren't. So at least until we descend into multi-core madness
>> it sounds like the current structures are fine, but it might be worth moving
>> the cap on the number of pid hash table entries at some point in the future.
> containers are using noticeably more pids, I think it is not a doubt...
> the question is whether it is worth doing something here _now_...
True. The break even point in terms of cache misses between a hash chain
and a binary tree is between 8 and 16 levels deep. Currently it looks like
we are close to that point but not over on a heavily loaded system.
So until we cross that line it probably doesn't make sense to change
the implementation, unless it makes multiple pid namespaces easier to
implement, and it doesn't look like it will significantly help that
case.
Eric
|
|
|
|
OpenVZ Forum
Members
Search
Help
Register
Login
Home
