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: speed up quiescent state detection
Date: Thu, 30 Dec 2004 16:36:54 +0100 [thread overview]
Message-ID: <41D42096.3020708@colorfullife.com> (raw)
In-Reply-To: <41D429C5.F32D7161@tv-sign.ru>
Oleg Nesterov wrote:
>On top of Manfred's 'rcu: simplify quiescent state detection', see
>http://marc.theaimsgroup.com/?l=linux-kernel&m=110433412126392
>
>Let's suppose that cpu is running idle thread or user level process,
>and the grace period was started.
>
>Afaics, currently we need 2 local timer interrupts to happen before
>this cpu can end its grace period.
>
>
>
I agree with you that the design is not optimal, but I must think about
it a bit more.
Right now the grace period handling consists out of three steps for each
cpu:
- start grace period (from timer irq)
- log quiescent state in ->passed_quiesc (from timer or schedule())
- end grace period (from timer irq)
This requires at least two timer ticks. Your patch would reduce that to
one timer tick, without changing the approach. I'm still thinking about
the design change I proposed: In each quiescent state: check if there is
a running grace period and if there is one, then mark the current cpu as
done.
Dipankar: What do you think?
--
Manfred
next prev parent reply other threads:[~2004-12-30 15:37 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-30 16:16 [PATCH] rcu: speed up quiescent state detection Oleg Nesterov
2004-12-30 15:36 ` Manfred Spraul [this message]
2004-12-30 17:22 ` 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=41D42096.3020708@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.