From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
To: Timo Sirainen <tss@iki.fi>
Cc: kosaki.motohiro@jp.fujitsu.com, Oleg Nesterov <oleg@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Bryan Donlan <bdonlan@gmail.com>,
Ulrich Drepper <drepper@redhat.com>,
WANG Cong <xiyou.wangcong@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: + prctl-add-pr_set_proctitle_area-option.patch added to -mm tree
Date: Wed, 11 Nov 2009 09:43:52 +0900 (JST) [thread overview]
Message-ID: <20091111090704.FD2D.A69D9226@jp.fujitsu.com> (raw)
In-Reply-To: <1257876016.3022.277.camel@timo-desktop>
> On Wed, 2009-11-11 at 02:48 +0900, KOSAKI Motohiro wrote:
> > There is unwritten reason. I hope to add /proc/[pid]/cmdline cache. It
> > help to avoid
> > ps getting stuck by mmap_sem.
>
> Can you explain this further? When would it cache the value and when
> would it be returned? I was at least hoping to avoid calling prctl()
> every time when I want process title changed.
Hmm...
I'm not intent it.
The setter's prctl() performance is not critical. Plus, current code
isn't so slow.
I mean ps -elf (or ps aux) read the /proc/pid/cmdline of all task.
It mean grabbing mmap_sem and read another task's mem for all task.
Then, A stress workload can kill ps performance easily.
Essentially, reading another process's memory is costly operation. but
it can be cached.
Some *BSD has similar mechanism.
Caution: This feature break SPT_ARGV style process title changing.
then, it should be optional feature and sould be able to enable by
admin's explicit operation.
2years after, probably this issue will disappear automatically. because
all setproctitle() using software try to use libc's setproctitle().
IOW, if libc has setproctitle(), nobody try to change own stack argv
string brutally.
> I think Solaris saves the first 80 chars of the initial cmdline to
> kernel memory and gives that to ps. I guess doing something similar and
> returning it only when userspace memory can't be accessed would be ok.
Linux does it too. but 16 chars.
prev parent reply other threads:[~2009-11-11 0:43 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-10 17:04 + prctl-add-pr_set_proctitle_area-option.patch added to -mm tree Oleg Nesterov
2009-11-10 17:23 ` Alan Cox
2009-11-10 17:48 ` KOSAKI Motohiro
2009-11-10 18:00 ` Timo Sirainen
2009-11-11 0:43 ` KOSAKI Motohiro [this message]
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=20091111090704.FD2D.A69D9226@jp.fujitsu.com \
--to=kosaki.motohiro@jp.fujitsu.com \
--cc=akpm@linux-foundation.org \
--cc=bdonlan@gmail.com \
--cc=drepper@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=tss@iki.fi \
--cc=xiyou.wangcong@gmail.com \
/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