All of lore.kernel.org
 help / color / mirror / Atom feed
From: Manfred Spraul <manfred@colorfullife.com>
To: Oleg Nesterov <oleg@tv-sign.ru>
Cc: linux-kernel@vger.kernel.org,
	Dipankar Sarma <dipankar@in.ibm.com>,
	Andrew Morton <akpm@osdl.org>
Subject: Re: PATCH? rcu: eliminate rcu_ctrlblk.lock
Date: Sat, 27 Nov 2004 18:56:08 +0100	[thread overview]
Message-ID: <41A8BFB8.3000804@colorfullife.com> (raw)
In-Reply-To: <41A8A57A.DD2338BB@tv-sign.ru>

Oleg Nesterov wrote:

>Hello.
>
>I am trying to understand the rcu implementetion.
>
>I can't understand why rcu_ctrlblk.seqcount is needed.
>It seems to me it can be replaced by a couple of barriers.
>
>  
>

Your patch would add one new corner case:

start: next_pending==1. rcp->cur == 11.
cpu 1: rcu_start_back sets next_pending to 0.
cpu 2: rdp->batch = rcp->cur + 1 [i.e. wait for end of period 12]
cpu 2: notices next_pending == 0, tries to acquire the spinlock [blocks]
cpu 1: rcp->cur++ [i.e. start period 12]
cpu 1: releases the spinlock
cpu 2: gets the spinlock, sets next_pending to 1 and exits.

Now next_pending is 1 [i.e. at the end of grace period 12 grace period 
13 is automatically started], although noone has callbacks waiting for 
period 13.

This is not fatal: the combination is rare, so perhaps we could tolerate 
the race. But on the other hand the sequence locks are outside of the 
hot paths and not much slower than a smp_rmb().

Dipankar - what do you think?

--
    Manfred

  reply	other threads:[~2004-11-27 17:56 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-27 16:04 PATCH? rcu: eliminate rcu_ctrlblk.lock Oleg Nesterov
2004-11-27 17:56 ` Manfred Spraul [this message]
2004-11-28 10:16   ` Oleg Nesterov

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=41A8BFB8.3000804@colorfullife.com \
    --to=manfred@colorfullife.com \
    --cc=akpm@osdl.org \
    --cc=dipankar@in.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@tv-sign.ru \
    /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.