All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ravikiran G Thirumalai <kiran@scalex86.org>
To: Christoph Lameter <clameter@engr.sgi.com>
Cc: Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org,
	"Shai Fultheim (Shai@scalex86.org)" <shai@scalex86.org>,
	nippung@calsoftinc.com
Subject: Re: [rfc][patch] Avoid taking global tasklist_lock for single threaded process at getrusage()
Date: Wed, 21 Dec 2005 13:35:28 -0800	[thread overview]
Message-ID: <20051221213528.GC4514@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.62.0512211318070.3443@schroedinger.engr.sgi.com>

On Wed, Dec 21, 2005 at 01:22:24PM -0800, Christoph Lameter wrote:
> On Wed, 21 Dec 2005, Ravikiran G Thirumalai wrote:
> 
> > We did look at that. Cases RUSAGE_CHILDREN and RUSAGE_SELF are always called by the 
> > current task, so we can avoid tasklist locking there.
> > getrusage for non-current tasks are always called with RUSAGE_BOTH.
> > We ensure we  always take the siglock for RUSAGE_BOTH case, so that the
> > p->signal* fields are protected and take the tasklist_lock only if we have 
> > to traverse the tasklist hashlist. Isn't this safe?
> 
> Sounds okay. But its complex in the way its is coded now and its easy to 
> assume that one can call getrusage with any parameter from inside the 
> kernel. Maybe we can have a couple of separate functions 
> 
> rusage_children()
> rusage_self()
> rusage_both()
> 
> ?
> 
> Only rusage_both would take a task_struct * parameter. The others would 
> only operate on current. Change all the locations that call getrusage with 
> RUSAGE_BOTH to call rusage_both().

Yes.  This would indeed be better. I will do that change.

Thanks,
Kiran

  reply	other threads:[~2005-12-21 21:35 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-21 18:23 [rfc][patch] Avoid taking global tasklist_lock for single threaded process at getrusage() Ravikiran G Thirumalai
2005-12-21 20:20 ` Christoph Lameter
2005-12-21 21:11   ` Ravikiran G Thirumalai
2005-12-21 21:22     ` Christoph Lameter
2005-12-21 21:35       ` Ravikiran G Thirumalai [this message]
2005-12-23 23:15       ` Ravikiran G Thirumalai
2005-12-24  0:13         ` Christoph Lameter
  -- strict thread matches above, loose matches on Subject: below --
2005-12-24  5:34 Nippun Goel
2005-12-24 17:52 Oleg Nesterov
2005-12-27 20:21 ` Christoph Lameter

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=20051221213528.GC4514@localhost.localdomain \
    --to=kiran@scalex86.org \
    --cc=akpm@osdl.org \
    --cc=clameter@engr.sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nippung@calsoftinc.com \
    --cc=shai@scalex86.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.