From: Tejun Heo <tj@kernel.org>
To: Cyrill Gorcunov <gorcunov@gmail.com>
Cc: Vasiliy Kulikov <segoon@openwall.com>,
Nathan Lynch <ntl@pobox.com>, Oren Laadan <orenl@cs.columbia.edu>,
Daniel Lezcano <dlezcano@fr.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>,
Pavel Emelyanov <xemul@parallels.com>,
linux-kernel@vger.kernel.org,
James Bottomley <jbottomley@parallels.com>,
LINUXFS-ML <linux-fsdevel@vger.kernel.org>,
containers@lists.osdl.org, Zan Lynx <zlynx@acm.org>,
Andi Kleen <andi@firstfloor.org>
Subject: Re: [RFC] fs, proc: Introduce the /proc/<pid>/map_files/ directory v2
Date: Thu, 25 Aug 2011 22:54:26 +0200 [thread overview]
Message-ID: <20110825205426.GO2803@mtj.dyndns.org> (raw)
In-Reply-To: <20110825170705.GA6387@sun>
Hello,
On Thu, Aug 25, 2011 at 09:07:05PM +0400, Cyrill Gorcunov wrote:
> This will force us to bloat proc_inode a bit more, since at moment we
> have a union such as
>
> struct proc_inode {
> struct pid *pid;
> union {
> int fd;
> unsigned long vm_start;
> };
> ...
>
> also it will require to make a buffer for names twice bigger as well.
> If all this not a problem -- then sure we can do that ;)
I'm not too familiar with this area but I don't think bloating it a
bit would be such a big problem. proc_inode is generated on the fly
as proc directories and files are accessed, so it's not like they'll
linearly hog down more memory with increasing number of entries (sysfs
had this sort of problem in the past).
Another thing is, I don't really see why we need vm_start, or fd for
that matter, in proc_inode at all. proc_inode is created on the fly
only as dentry gets instantiated on demand, which means we always have
d_name on hand to tell what the file is supposed to point to. In
fact, the code already uses name_to_int() to extract fd from d_name.
Hmmm... well yeah, it actually seems that proc_inode->fd is never used
and we can simply remove it.
So, we can do the same thing w/ these mapping files too. We just need
name_to_map_range() or something. Also, for most address ranges, the
name sould fit inside the inline name in dentry (32 bytes on 64bit),
so it really isn't gonna bloat anything.
Thanks.
--
tejun
next prev parent reply other threads:[~2011-08-25 20:54 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-24 8:53 [RFC] fs, proc: Introduce the /proc/<pid>/map_files/ directory v2 Cyrill Gorcunov
2011-08-24 9:21 ` Pekka Enberg
2011-08-24 9:33 ` Pavel Emelyanov
2011-08-24 9:34 ` Tejun Heo
2011-08-24 9:37 ` Cyrill Gorcunov
2011-08-24 9:41 ` Cyrill Gorcunov
2011-08-24 11:18 ` Vasiliy Kulikov
2011-08-24 11:31 ` Cyrill Gorcunov
2011-08-25 8:29 ` Cyrill Gorcunov
2011-08-25 17:01 ` Tejun Heo
2011-08-25 17:05 ` Pavel Emelyanov
2011-08-25 17:21 ` Cyrill Gorcunov
2011-08-25 17:25 ` Pavel Emelyanov
2011-08-25 17:27 ` Tejun Heo
2011-08-25 17:34 ` Cyrill Gorcunov
2011-08-25 17:07 ` Cyrill Gorcunov
2011-08-25 20:54 ` Tejun Heo [this message]
2011-08-25 21:12 ` Tejun Heo
2011-08-25 21:34 ` Cyrill Gorcunov
2011-08-25 21:39 ` Tejun Heo
2011-08-26 6:58 ` Cyrill Gorcunov
2011-08-26 11:29 ` Cyrill Gorcunov
2011-08-26 12:28 ` Kirill A. Shutemov
2011-08-26 12:39 ` Cyrill Gorcunov
2011-08-26 13:16 ` Cyrill Gorcunov
2011-08-26 14:06 ` Tejun Heo
2011-08-26 14:23 ` Kirill A. Shutemov
2011-08-26 14:27 ` Tejun Heo
2011-08-25 17:11 ` Cyrill Gorcunov
2011-08-25 17:36 ` Vasiliy Kulikov
2011-08-25 17:39 ` Cyrill Gorcunov
2011-08-25 17:54 ` Vasiliy Kulikov
2011-08-25 18:13 ` Cyrill Gorcunov
2011-08-24 15:05 ` Zan Lynx
2011-08-24 15:19 ` Pavel Emelyanov
2011-08-24 17:36 ` Andi Kleen
2011-08-25 6:42 ` Pavel Emelyanov
2011-08-25 14:04 ` Andi Kleen
2011-08-25 14:30 ` Cyrill Gorcunov
2011-08-25 14:47 ` Pavel Emelyanov
2011-08-24 15:22 ` Cyrill Gorcunov
2011-09-13 14:14 ` Pavel Machek
2011-09-13 14:20 ` Pavel Emelyanov
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=20110825205426.GO2803@mtj.dyndns.org \
--to=tj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=containers@lists.osdl.org \
--cc=dlezcano@fr.ibm.com \
--cc=gorcunov@gmail.com \
--cc=jbottomley@parallels.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ntl@pobox.com \
--cc=orenl@cs.columbia.edu \
--cc=segoon@openwall.com \
--cc=xemul@parallels.com \
--cc=zlynx@acm.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;
as well as URLs for NNTP newsgroup(s).