public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: "André Goddard Rosa" <andre.goddard@gmail.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, "Jiri Kosina" <jkosina@suse.cz>
Subject: Re: [PATCH 1/2] pid: tighten pidmap spinlock critical section by removing kfree()
Date: Mon, 23 Nov 2009 15:03:23 +0100	[thread overview]
Message-ID: <20091123140323.GA4495@redhat.com> (raw)
In-Reply-To: <84144f020911230138v11b18709q28c186f9260f6d66@mail.gmail.com>

On 11/23, Pekka Enberg wrote:
> (Adding some CC's.)
>
> On Sat, Nov 21, 2009 at 2:16 PM, André Goddard Rosa
> <andre.goddard@gmail.com> wrote:
> > Avoid calling kfree() under pidmap spinlock, calling it afterwards.
> >
> > Normally kfree() is very fast, but sometimes it can be slow, so avoid
> > calling it under the spinlock if we can.

kfree() is called when we race with another process which also
finds map->page == NULL, allocs the new page and takes pidmap_lock
before us. This is extremely unlikely case, right?

> > @@ -141,11 +141,12 @@ static int alloc_pidmap(struct pid_namespace *pid_ns)
> >                         * installing it:
> >                         */
> >                        spin_lock_irq(&pidmap_lock);
> > -                       if (map->page)
> > -                               kfree(page);
> > -                       else
> > +                       if (!map->page) {
> >                                map->page = page;
> > +                               page = NULL;
> > +                       }
> >                        spin_unlock_irq(&pidmap_lock);
> > +                       kfree(page);

And this change pessimizes (a little bit) the likely case, when
the race doesn't happen. And imho this change doesn't make the
code more readable.

But this is subjective, and technically the patch is correct
afaics.

> >                        if (unlikely(!map->page))
> >                         �

Hmm. Off-topic, but why alloc_pidmap() does not do this right
after kzalloc() ?

Oleg.


  reply	other threads:[~2009-11-23 14:08 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-21 12:16 [PATCH 0/2] pid: tighten pidmap spinlock section and clean up André Goddard Rosa
2009-11-21 12:16 ` [PATCH 1/2] pid: tighten pidmap spinlock critical section by removing kfree() André Goddard Rosa
2009-11-23  9:38   ` Pekka Enberg
2009-11-23 14:03     ` Oleg Nesterov [this message]
2009-11-23 15:26       ` André Goddard Rosa
2009-12-04 22:38   ` [PATCH 1/2][resend] " Andrew Morton
2009-11-21 12:16 ` [PATCH 2/2] pid: reduce code size by using a pointer to iterate over array André Goddard Rosa

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=20091123140323.GA4495@redhat.com \
    --to=oleg@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=andre.goddard@gmail.com \
    --cc=jkosina@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=penberg@cs.helsinki.fi \
    /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