From: Oleg Nesterov <oleg@redhat.com>
To: Jiri Pirko <jpirko@redhat.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
linux-kernel@vger.kernel.org, Hugh Dickins <hugh@veritas.com>
Subject: Re: [PATCH, RESEND3] getrusage: fill ru_maxrss value
Date: Wed, 24 Dec 2008 18:42:48 +0100 [thread overview]
Message-ID: <20081224174248.GA15887@redhat.com> (raw)
In-Reply-To: <20081224121738.68c5d1e6@psychotron.englab.brq.redhat.com>
On 12/24, Jiri Pirko wrote:
>
> On Wed, 24 Dec 2008 16:37:55 +0900 (JST)
> KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote:
>
> > > @@ -870,6 +870,7 @@ static int de_thread(struct task_struct *tsk)
> > > sig->notify_count = 0;
> > >
> > > no_thread_group:
> > > + sig->maxrss = 0;
> > > exit_itimers(sig);
> > > flush_itimer_signals();
> > > if (leader)
> >
> > I don't know getrusage correct behavior so detail.
> > Why don't update parent process's sig->cmaxrss ?
> Because exec affects only this task and we want to forgot maxrss value.
> That does not implicate that we want to forgot highest maxrss value of
> our childs because exec does not affect them. I think this is right
> behavior.
Well, I don't understand the explanation above, but I agree with the
code ;)
parent process's sig->cmaxrss, like other parent->signal->cxxxx fields
should only be changed by wait_task_zombie(), ->cmaxrss is not special.
The real question is why do we clear sig->maxrss on exec. Again, I agree
with the patch because this is consistent with xacct_add_tsk/etc, but
it is not clear to me whether this right or not.
Yes, technically this is right because we have the new ->mm after exec,
but this is "transparent" for the user-space. For example, we don't
clear ->min_flt on exec...
Perhaps it makes sense to change the bprm_mm_init's path to do
if (!PF_FORKNOEXEC)
new_mm->hiwater_xxx = old_mm->hiwater_xxx;
But once again, imho the patch does the right thing for now.
> > > unsigned long min_flt, maj_flt, cmin_flt, cmaj_flt;
> > > unsigned long inblock, oublock, cinblock, coublock;
> > > struct task_io_accounting ioac;
> > > + unsigned long maxrss, cmaxrss;
> >
> > unsigned long inblock, oublock, cinblock, coublock;
> > unsigned long maxrss, cmaxrss;
> > struct task_io_accounting ioac;
> >
> > is better.
> > I like related member sit on nearly place.
> No problem with this.
Agreed.
> > > + if (who != RUSAGE_CHILDREN) {
> > > + task_lock(p);
> > > + if (p->mm) {
> > > + unsigned long maxrss = get_mm_hiwater_rss(p->mm);
> > > +
> > > + if (r->ru_maxrss < maxrss)
> > > + r->ru_maxrss = maxrss;
> > > + }
> > > + task_unlock(p);
> >
> > get_task_mm() and mmput() instead task_lock() is better?
> Maybe it's better looking. I wanted to use these too. Oleg suggested to
> optimize the way it is in the patch. I can change it, no problem.
I have no problem with get_task_mm() too, the optimization is minor.
(btw, that is why I didn't like the fact we discussed this patch privately,
imho it is always better to do on lkml).
> > > + r->ru_maxrss <<= PAGE_SHIFT - 10;
> > > }
> >
> > using local variable is better because local variable can stay on
> > register by compiler easily, but indirect access doesn't.
> OK
Not that I have a strong opinion, but the code looks simpler without
the local var. Up to you.
> > and we need good comment. e.g. /* Convert to KB */
> > or good macros (likely linux/fs/proc/meminfo.c::K() macro)
Yes! Please ;) I just can't parse the code above, I am not compiler.
Even
r->ru_maxrss *= (PAGE_SIZE / 1024); /* convert pages to KBs */
is much better, imho. Or at least just add the comment, so the
poor reader can understand what the code does without parsing.
> > In addision, you also need change man pages and notice to linux-api mailing list.
> I cc'ed this list while I was sending the patch.
Hmm. The biggest mistake with this patch is that you lost the
CC list completely ;) Adding Hugh.
> I was not aware I
> should change the man page. Will do that too.
Well. I don't think you must change the man page. Of course it
would be nice if you do, but in a separate patch please. But
you must cc Michael at least ;)
Oleg.
next prev parent reply other threads:[~2008-12-24 17:44 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-18 12:59 [PATCH, RESEND3] getrusage: fill ru_maxrss value Jiri Pirko
2008-12-18 12:59 ` Jiri Pirko
2008-12-24 7:37 ` KOSAKI Motohiro
2008-12-24 11:17 ` Jiri Pirko
2008-12-24 17:42 ` Oleg Nesterov [this message]
2008-12-25 0:11 ` Jiri Pirko
2008-12-25 4:46 ` KOSAKI Motohiro
2008-12-25 12:44 ` Jiri Pirko
2008-12-25 14:43 ` Oleg Nesterov
2008-12-30 11:10 ` 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=20081224174248.GA15887@redhat.com \
--to=oleg@redhat.com \
--cc=hugh@veritas.com \
--cc=jpirko@redhat.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.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 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.