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
next prev 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.