From: Pavel Emelyanov <xemul@parallels.com>
To: Pedro Alves <pedro@codesourcery.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Cyrill Gorcunov <gorcunov@gmail.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Tejun Heo <tj@kernel.org>, Andrew Vagin <avagin@openvz.org>,
Serge Hallyn <serge.hallyn@canonical.com>,
Vasiliy Kulikov <segoon@openwall.com>
Subject: Re: [rfc 2/3] fs, proc: Introduce the Children: line in /proc/<pid>/status
Date: Fri, 02 Dec 2011 18:37:10 +0400 [thread overview]
Message-ID: <4ED8E296.3070005@parallels.com> (raw)
In-Reply-To: <201112021425.44897.pedro@codesourcery.com>
On 12/02/2011 06:25 PM, Pedro Alves wrote:
> On Friday 02 December 2011 14:17:08, Pavel Emelyanov wrote:
>
>> O_O OK, I was wrong, they do live there. But I consider this as bug.
>
> You can't change that. It'd break current gdb at least.
OMG!
>> I.e. each task will be shown multiple times, which is not very fun, but memory exhaustive from my POV.
>
> Now that is a good argument against hard linking. But not if you make
> the entries under children/ symlinks. Then find doesn't recurse. And
> then
>
> $ find -L /proc/PID/
>
> does recurse and give you the whole tree. Which I'd say is
> actually useful...
It is useful, but the /proc/pid/children file solves the same problem in a much
more simple way. The memory usage by proc (one file vs one dir and a set of files)
is less and time to lookup a child is also less (read + lookup vs readdir + lookup
(symlink itself) + lookup (symlink resolve)).
Yes, it doesn't allow you to have fun with find, but frankly, do you really need
this? Even if we're talking about gdb -- reading /proc/pid/children is not harder
and not easier than readdir-ing it.
IOW - what's the real benefit of a directory with symlinks against a file except
for a fun?
Thanks,
Pavel
next prev parent reply other threads:[~2011-12-02 14:37 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-29 19:12 [rfc 0/3] A small bundle in a sake of checkpoint/restore Cyrill Gorcunov
2011-11-29 19:12 ` [rfc 1/3] fs, proc: Add start_data, end_data, start_brk members to /proc/$pid/stat Cyrill Gorcunov
2011-11-29 20:06 ` Kees Cook
2011-12-02 0:24 ` Alexey Dobriyan
2011-12-02 7:28 ` Cyrill Gorcunov
2011-12-02 19:23 ` Kees Cook
2011-12-02 19:28 ` Cyrill Gorcunov
2011-11-29 20:32 ` Serge Hallyn
2011-11-30 5:04 ` KAMEZAWA Hiroyuki
2011-11-29 19:12 ` [rfc 2/3] fs, proc: Introduce the Children: line in /proc/<pid>/status Cyrill Gorcunov
2011-11-30 5:00 ` KAMEZAWA Hiroyuki
2011-11-30 6:05 ` Cyrill Gorcunov
2011-12-01 9:54 ` Cyrill Gorcunov
2011-12-01 15:43 ` Tejun Heo
2011-12-01 15:53 ` Cyrill Gorcunov
2011-12-01 16:07 ` Tejun Heo
2011-12-01 21:29 ` Andrew Morton
2011-12-01 21:38 ` Cyrill Gorcunov
2011-12-02 0:40 ` KAMEZAWA Hiroyuki
2011-12-02 12:41 ` Pedro Alves
2011-12-02 12:43 ` Pavel Emelyanov
2011-12-02 12:45 ` Cyrill Gorcunov
2011-12-02 13:10 ` Pedro Alves
2011-12-02 13:40 ` Pedro Alves
2011-12-02 12:58 ` Pedro Alves
2011-12-02 13:16 ` Pavel Emelyanov
2011-12-02 13:44 ` Pedro Alves
2011-12-02 13:52 ` Pavel Emelyanov
2011-12-02 14:00 ` Pedro Alves
2011-12-02 14:17 ` Pavel Emelyanov
2011-12-02 14:25 ` Pedro Alves
2011-12-02 14:37 ` Pavel Emelyanov [this message]
2011-12-02 14:45 ` Pedro Alves
2011-11-29 19:12 ` [rfc 3/3] prctl: Add PR_SET_MM codes to tune up mm_struct entires Cyrill Gorcunov
2011-11-29 20:19 ` Kees Cook
2011-11-29 20:29 ` Cyrill Gorcunov
2011-11-29 20:37 ` Cyrill Gorcunov
2011-11-29 20:40 ` Kees Cook
2011-11-29 20:47 ` Cyrill Gorcunov
2011-11-30 17:37 ` Cyrill Gorcunov
2011-11-30 18:10 ` Kees Cook
2011-11-30 18:23 ` Cyrill Gorcunov
2011-11-30 21:06 ` Cyrill Gorcunov
2011-12-07 12:27 ` Cyrill Gorcunov
2011-12-07 22:43 ` Andrew Morton
2011-12-08 7:07 ` Cyrill Gorcunov
2011-12-08 7:15 ` Andrew Morton
2011-12-08 7:30 ` Cyrill Gorcunov
2011-11-29 20:37 ` Kees Cook
2011-11-29 20:49 ` Serge Hallyn
2011-11-29 20:55 ` Cyrill Gorcunov
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=4ED8E296.3070005@parallels.com \
--to=xemul@parallels.com \
--cc=akpm@linux-foundation.org \
--cc=avagin@openvz.org \
--cc=gorcunov@gmail.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pedro@codesourcery.com \
--cc=segoon@openwall.com \
--cc=serge.hallyn@canonical.com \
--cc=tj@kernel.org \
/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