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_data.last_qsctr
Date: Wed, 29 Dec 2004 16:37:31 +0100	[thread overview]
Message-ID: <41D2CF3B.4040304@colorfullife.com> (raw)
In-Reply-To: <41AA0D5F.21CB9ED3@tv-sign.ru>

Oleg Nesterov wrote:

>last_qsctr is used in rcu_check_quiescent_state() exclusively.
>We can reset qsctr at the start of the grace period, and then
>just test qsctr against 0.
>
>  
>
It seems the patch got lost, I've updated it a bit and resent it to Andrew.

But: I think there is the potential for an even larger cleanup, although 
this would be more a rewrite:
Get rid of rcu_check_quiescent_state and instead use something like this 
in rcu_qsctr_inc:

static inline void rcu_qsctr_inc(int cpu)
{
        struct rcu_data *rdp = &per_cpu(rcu_data, cpu);
        if (rdp->quiescbatch != rcp->cur) {
             /* a new grace period is running. And we are at a quiescent
              * point, so complete it
              */
             spin_lock(&rsp->lock);
             rdp->quiescbatch = rcp->cur;
             cpu_quiet(rdp->cpu, rcp, rsp);
            spin_unlock(&rsp->lock);
     }
}

It's just an idea, it needs testing on big systems - does reading from 
the global rcp from every schedule call cause any problems? The cache 
line is virtually read-only, so it shouldn't cause trashing, but who knows?

--
    Manfred

  parent reply	other threads:[~2004-12-29 15:39 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-28 17:39 [PATCH] rcu: eliminate rcu_data.last_qsctr Oleg Nesterov
2004-11-29 19:00 ` Manfred Spraul
2004-12-29 15:37 ` Manfred Spraul [this message]
2005-01-05 18:30   ` Paul E. McKenney

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=41D2CF3B.4040304@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.