From: Oleg Nesterov <oleg@redhat.com>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Jiri Pirko <jpirko@redhat.com>,
linux-kernel@vger.kernel.org, Hugh Dickins <hugh@veritas.com>,
linux-mm <linux-mm@kvack.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH for -mm] getrusage: fill ru_maxrss value
Date: Sat, 3 Jan 2009 18:59:13 +0100 [thread overview]
Message-ID: <20090103175913.GA21180@redhat.com> (raw)
In-Reply-To: <20081231213705.1293.KOSAKI.MOTOHIRO@jp.fujitsu.com>
sorry for delay!
On 12/31, KOSAKI Motohiro wrote:
>
> Jiri's resend3 -> v1
> - At wait_task_zombie(), parent process doesn't only collect child maxrss,
> but also cmaxrss.
Ah yes, this looks very right to me.
> - ru_maxrss inherit at exec()
I must admit, I hate this ;)
That said, I agree with you point about compatibility. So I have to
agree with this change.
Still, I'd like to know what other people think ;)
And I also agree that xacct is linux specific feature, but I still
I dislike the fact that xacct and getrusage report different numbers.
Perhaps we should change xacct as well?
> --- a/kernel/exit.c 2008-12-29 23:27:59.000000000 +0900
> +++ b/kernel/exit.c 2008-12-31 21:08:08.000000000 +0900
> @@ -1053,6 +1053,12 @@ NORET_TYPE void do_exit(long code)
> if (group_dead) {
> hrtimer_cancel(&tsk->signal->real_timer);
> exit_itimers(tsk->signal);
> + if (tsk->mm) {
> + unsigned long hiwater_rss = get_mm_hiwater_rss(tsk->mm);
> +
> + if (tsk->signal->maxrss < hiwater_rss)
> + tsk->signal->maxrss = hiwater_rss;
> + }
[...snip...]
> --- a/fs/exec.c 2008-12-25 08:26:37.000000000 +0900
> +++ b/fs/exec.c 2008-12-31 21:11:28.000000000 +0900
> @@ -870,6 +870,13 @@ static int de_thread(struct task_struct
> sig->notify_count = 0;
>
> no_thread_group:
> + if (current->mm) {
> + unsigned long hiwater_rss = get_mm_hiwater_rss(current->mm);
> +
> + if (sig->maxrss < hiwater_rss)
> + sig->maxrss = hiwater_rss;
> + }
Perhaps it makes sense to factor out this code and make a helper?
Unfortunately, exit_mm() and exec_mmap() do not have the common
path which can update sig->maxrss, mm_release() can't do this...
> + if (who != RUSAGE_CHILDREN) {
> + struct mm_struct *mm = get_task_mm(p);
> + if (mm) {
> + unsigned long hiwater_rss = get_mm_hiwater_rss(mm);
> +
> + if (maxrss < hiwater_rss)
> + maxrss = hiwater_rss;
> + mmput(mm);
> + }
> + }
> + r->ru_maxrss = maxrss * (PAGE_SIZE / 1024); /* convert pages to KBs */
Hmm... So, RUSAGE_THREAD always report maxrss == get_mm_hiwater_rss(mm)
and ignores signal->maxrss. Doesn't look right to me...
Unless I missed something, Jiris's patch was fine, but given that now
we inherit maxrss at exec(), signal->maxrss can have the "inherited"
value?
Oleg.
WARNING: multiple messages have this Message-ID (diff)
From: Oleg Nesterov <oleg@redhat.com>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Jiri Pirko <jpirko@redhat.com>,
linux-kernel@vger.kernel.org, Hugh Dickins <hugh@veritas.com>,
linux-mm <linux-mm@kvack.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH for -mm] getrusage: fill ru_maxrss value
Date: Sat, 3 Jan 2009 18:59:13 +0100 [thread overview]
Message-ID: <20090103175913.GA21180@redhat.com> (raw)
In-Reply-To: <20081231213705.1293.KOSAKI.MOTOHIRO@jp.fujitsu.com>
sorry for delay!
On 12/31, KOSAKI Motohiro wrote:
>
> Jiri's resend3 -> v1
> - At wait_task_zombie(), parent process doesn't only collect child maxrss,
> but also cmaxrss.
Ah yes, this looks very right to me.
> - ru_maxrss inherit at exec()
I must admit, I hate this ;)
That said, I agree with you point about compatibility. So I have to
agree with this change.
Still, I'd like to know what other people think ;)
And I also agree that xacct is linux specific feature, but I still
I dislike the fact that xacct and getrusage report different numbers.
Perhaps we should change xacct as well?
> --- a/kernel/exit.c 2008-12-29 23:27:59.000000000 +0900
> +++ b/kernel/exit.c 2008-12-31 21:08:08.000000000 +0900
> @@ -1053,6 +1053,12 @@ NORET_TYPE void do_exit(long code)
> if (group_dead) {
> hrtimer_cancel(&tsk->signal->real_timer);
> exit_itimers(tsk->signal);
> + if (tsk->mm) {
> + unsigned long hiwater_rss = get_mm_hiwater_rss(tsk->mm);
> +
> + if (tsk->signal->maxrss < hiwater_rss)
> + tsk->signal->maxrss = hiwater_rss;
> + }
[...snip...]
> --- a/fs/exec.c 2008-12-25 08:26:37.000000000 +0900
> +++ b/fs/exec.c 2008-12-31 21:11:28.000000000 +0900
> @@ -870,6 +870,13 @@ static int de_thread(struct task_struct
> sig->notify_count = 0;
>
> no_thread_group:
> + if (current->mm) {
> + unsigned long hiwater_rss = get_mm_hiwater_rss(current->mm);
> +
> + if (sig->maxrss < hiwater_rss)
> + sig->maxrss = hiwater_rss;
> + }
Perhaps it makes sense to factor out this code and make a helper?
Unfortunately, exit_mm() and exec_mmap() do not have the common
path which can update sig->maxrss, mm_release() can't do this...
> + if (who != RUSAGE_CHILDREN) {
> + struct mm_struct *mm = get_task_mm(p);
> + if (mm) {
> + unsigned long hiwater_rss = get_mm_hiwater_rss(mm);
> +
> + if (maxrss < hiwater_rss)
> + maxrss = hiwater_rss;
> + mmput(mm);
> + }
> + }
> + r->ru_maxrss = maxrss * (PAGE_SIZE / 1024); /* convert pages to KBs */
Hmm... So, RUSAGE_THREAD always report maxrss == get_mm_hiwater_rss(mm)
and ignores signal->maxrss. Doesn't look right to me...
Unless I missed something, Jiris's patch was fine, but given that now
we inherit maxrss at exec(), signal->maxrss can have the "inherited"
value?
Oleg.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2009-01-03 18:01 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-30 11:15 [PATCH for -mm] getrusage: fill ru_maxrss value KOSAKI Motohiro
2008-12-30 11:15 ` KOSAKI Motohiro
2008-12-31 10:08 ` Jiri Pirko
2008-12-31 10:08 ` Jiri Pirko
2008-12-31 12:42 ` KOSAKI Motohiro
2008-12-31 12:42 ` KOSAKI Motohiro
2008-12-31 18:08 ` Jiri Pirko
2008-12-31 18:08 ` Jiri Pirko
2009-01-03 17:59 ` Oleg Nesterov [this message]
2009-01-03 17:59 ` Oleg Nesterov
2009-01-03 21:13 ` KOSAKI Motohiro
2009-01-03 21:13 ` KOSAKI Motohiro
2009-01-05 15:32 ` Jiri Pirko
2009-01-05 15:32 ` Jiri Pirko
2009-01-05 22:13 ` Andrew Morton
2009-01-05 22:13 ` Andrew Morton
2009-01-06 9:48 ` Jiri Pirko
2009-01-06 9:48 ` Jiri Pirko
2009-04-02 20:47 ` Andrew Morton
2009-04-02 20:47 ` Andrew Morton
2009-04-02 21:13 ` Ingo Molnar
2009-04-02 21:13 ` Ingo Molnar
2009-04-05 8:49 ` Jiri Pirko
2009-04-05 8:49 ` Jiri Pirko
2009-04-05 17:24 ` Hugh Dickins
2009-04-05 17:24 ` Hugh Dickins
2009-04-06 0:21 ` KOSAKI Motohiro
2009-04-06 0:21 ` KOSAKI Motohiro
2009-04-06 7:22 ` Hugh Dickins
2009-04-06 7:22 ` Hugh Dickins
2009-06-17 20:21 ` Andrew Morton
2009-06-17 20:21 ` Andrew Morton
2009-06-18 0:57 ` KOSAKI Motohiro
2009-06-18 0:57 ` KOSAKI Motohiro
2009-09-07 2:58 ` KOSAKI Motohiro
2009-09-07 2:58 ` KOSAKI Motohiro
2009-09-09 20:46 ` Andrew Morton
2009-09-09 20:46 ` Andrew Morton
2009-09-09 23:17 ` KOSAKI Motohiro
2009-09-09 23:17 ` KOSAKI Motohiro
2009-09-09 23:32 ` Andrew Morton
2009-09-09 23:32 ` Andrew Morton
2009-09-09 23:37 ` KOSAKI Motohiro
2009-09-09 23:37 ` KOSAKI Motohiro
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=20090103175913.GA21180@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=hugh@veritas.com \
--cc=jpirko@redhat.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.