From: ebiederm@xmission.com (Eric W. Biederman)
To: Kirill Korotaev <dev@sw.ru>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
containers@lists.osdl.org, linux-kernel@vger.kernel.org,
Oleg Nesterov <oleg@tv-sign.ru>
Subject: Re: [Containers] [PATCH 6/7] vt: Update spawnpid to be a struct pid_t
Date: Wed, 16 Aug 2006 08:23:26 -0600 [thread overview]
Message-ID: <m1psf04v4x.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <44E2D175.1010506@sw.ru> (Kirill Korotaev's message of "Wed, 16 Aug 2006 12:04:05 +0400")
Kirill Korotaev <dev@sw.ru> writes:
>> Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
>>
>>>Ar Maw, 2006-08-15 am 12:23 -0600, ysgrifennodd Eric W. Biederman:
>>>
>>>>This keeps the wrong process from being notified if the
>>>>daemon to spawn a new console dies.
>>>
>>>Not sure why we count pids not task structs but within the proposed
>>>implementation this appears correct so
>> Basically struct pid is relatively cheap, 64bytes or so.
>> struct task is expensive 10K or so, when all of the stacks
>> and everything are included.
>> Counting pids allows the task to exit in user space and free up
>> all of it's memory.
>> When /proc used to count the task struct it was fairly easy to
>> deliberately oom a 32bit machine just by open up directories in
>> /proc and then having the process exit. rlimits didn't help because
>> we don't count processes that have exited.
> hey, hey. your patch doesn't help in this situation (much)!
> inodes and dentries can still consume much memory.
> it just makes the situation a bit better.
It does help. The size of the locked memory is better and we
account for the used inodes and dentries. As I recall the inode+dentry
is less than 1k. The number of open file handle rlimit at least
lets the existing limits work. The core improvement is not allowing
an escape from our accounting mechanism for one of our biggest data
structures.
> I wonder whether it is easy to have the following done with your implementation:
> container tasks visible from host. theoretically having 2 pids (vpid, pid)
> it should be implementable. Do you see any obstacles?
I seen no problem for having tasks have N pid numbers. The trick
is to create a hash table entry (struct pid) that when has a pointer
to the real struct pid. It won't be the classic pid,vpid. All pids
will be equally real.
My intention is to give a process a pid in each namespace that it has
an ancestor in.
> in other regards patches look pretty good. Good job!
Thanks.
Eric
next prev parent reply other threads:[~2006-08-16 14:24 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-15 18:21 Start using struct pid Eric W. Biederman
2006-08-15 18:23 ` [PATCH 1/7] pid: Implement access helpers for a tacks various process groups Eric W. Biederman
2006-08-15 18:40 ` Dave Hansen
2006-08-15 19:03 ` Eric W. Biederman
2006-08-16 8:04 ` [Containers] " Kirill Korotaev
2006-08-15 18:23 ` [PATCH 2/7] pid: Add do_each_pid_task Eric W. Biederman
2006-08-16 3:10 ` [Containers] " Serge E. Hallyn
2006-08-16 4:28 ` Andrew Morton
2006-08-16 6:15 ` Eric W. Biederman
2006-08-16 6:34 ` Eric W. Biederman
2006-08-16 11:57 ` Serge E. Hallyn
2006-08-16 19:17 ` Oleg Nesterov
2006-08-17 21:16 ` [PATCH -mm] simplify pid iterators Oleg Nesterov
2006-08-15 18:23 ` [PATCH 3/7] pid: Implement signal functions that take a struct pid * Eric W. Biederman
2006-08-15 18:23 ` [PATCH 4/7] pid: Export the symbols needed to use " Eric W. Biederman
2006-08-15 18:23 ` [PATCH 5/7] pid: Implement pid_nr Eric W. Biederman
2006-08-15 18:37 ` Dave Hansen
2006-08-15 19:00 ` Eric W. Biederman
2006-08-15 19:15 ` [Containers] " Dave Hansen
2006-08-16 6:29 ` Eric W. Biederman
2006-08-16 16:27 ` Jan Engelhardt
2006-08-16 17:48 ` Eric W. Biederman
2006-08-16 18:19 ` Oleg Nesterov
2006-08-16 16:18 ` Eric W. Biederman
2006-08-16 21:03 ` Oleg Nesterov
2006-08-16 17:18 ` Eric W. Biederman
2006-08-15 18:23 ` [PATCH 6/7] vt: Update spawnpid to be a struct pid_t Eric W. Biederman
2006-08-15 18:53 ` Alan Cox
2006-08-15 18:45 ` Eric W. Biederman
2006-08-16 8:04 ` [Containers] " Kirill Korotaev
2006-08-16 14:23 ` Eric W. Biederman [this message]
2006-08-15 19:38 ` Ray Lehtiniemi
2006-08-16 19:35 ` Oleg Nesterov
2006-08-16 15:43 ` Andrew Morton
2006-08-16 17:55 ` Eric W. Biederman
2006-08-15 18:23 ` [PATCH 7/7] file: Modify struct fown_struct to use a struct pid Eric W. Biederman
2006-08-16 18:45 ` Oleg Nesterov
2006-08-16 18:48 ` Oleg Nesterov
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=m1psf04v4x.fsf@ebiederm.dsl.xmission.com \
--to=ebiederm@xmission.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=containers@lists.osdl.org \
--cc=dev@sw.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@tv-sign.ru \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome