public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Claudio Scordino <cloud.of.andor@gmail.com>
To: "Ulrich Drepper" <drepper@gmail.com>
Cc: "Andrew Morton" <akpm@osdl.org>,
	linux-kernel@vger.kernel.org, luto@myrealbox.com,
	alan@lxorguk.ukuu.org.uk, torvalds@osdl.org,
	kernel-janitors@lists.osdl.org, bert.hubert@netherlabs.nl
Subject: Re: [PATCH] Extending getrusage
Date: Sat, 22 Apr 2006 12:25:30 +0200	[thread overview]
Message-ID: <200604221225.31851.cloud.of.andor@gmail.com> (raw)
In-Reply-To: <a36005b50604210732h69f4408ey99b7895de8dbd902@mail.gmail.com>

On Friday 21 April 2006 16:32, Ulrich Drepper wrote:
> On 4/21/06, Claudio Scordino <cloud.of.andor@gmail.com> wrote:
> > Recently, while writing some code at user level, I needed a fast way
> > to have such information about another process.
> 
> That's not very specific.  And one program isn't really a compelling
> reason.  You should specify with some level of detail why you need
> that information and why you cannot depend on collaboration of the
> process you try to get the information for.

I'm just adding a new feature "for free":

- Without adding any new syscall
- Without changing the prototype of the current syscall (sys_getrusage)
- Ensuring backward compatibility (all old programs will continue to work properly)

This new feature can be used by any process that needs to profile another process for whatever reason.

Since it just adds a new feature without any drawback, I don't understand why it would be wrong...
 
> 
> > -               return -EINVAL;
> > -       return getrusage(current, who, ru);
> > +       struct rusage r;
> > +       struct task_struct *tsk = current;
> > +       read_lock(&tasklist_lock);
> 
> You are introducing scalability problems where there were none before.
>  Even if there is some justification revealed in the end IMO the patch
> shouldn't be accepted in this form.  You should not slow down the
> normal case of operation.  If the current thread is observed the lock
> isn't needed.

I think you're wrong: I'm not introducing any *new* scalability issue. 

Currently the code is:

asmlinkage long sys_getrusage(int who, struct rusage __user *ru)
{
        if (who != RUSAGE_SELF && who != RUSAGE_CHILDREN)
                return -EINVAL;
        return getrusage(current, who, ru);
}

which in turn calls

int getrusage(struct task_struct *p, int who, struct rusage __user *ru)
{
        struct rusage r;
        read_lock(&tasklist_lock);
        k_getrusage(p, who, &r);
        read_unlock(&tasklist_lock);
        return copy_to_user(ru, &r, sizeof(r)) ? -EFAULT : 0;
}

As you can see, the lock is acquired also when not needed. That's how it is currently implemented.

With my patch, k_getrusage is called directly from sys_getrusage without going through getrusage.

               Claudio





      reply	other threads:[~2006-04-22 20:49 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-20 15:21 [PATCH] Extending getrusage Claudio Scordino
2006-04-20 23:21 ` Andrew Morton
2006-04-21  7:41   ` bert hubert
2006-04-21 10:05     ` Claudio Scordino
2006-04-21 14:32       ` Ulrich Drepper
2006-04-22 10:25         ` Claudio Scordino [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=200604221225.31851.cloud.of.andor@gmail.com \
    --to=cloud.of.andor@gmail.com \
    --cc=akpm@osdl.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=bert.hubert@netherlabs.nl \
    --cc=drepper@gmail.com \
    --cc=kernel-janitors@lists.osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@myrealbox.com \
    --cc=torvalds@osdl.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