From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: axboe@kernel.dk, dm-devel@redhat.com,
Mikulas Patocka <mpatocka@redhat.com>,
linux-kernel@vger.kernel.org,
"Alasdair G. Kergon" <agk@redhat.com>
Subject: Re: [PATCH] backing-dev: use synchronize_rcu_expedited instead of synchronize_rcu
Date: Thu, 2 Feb 2012 16:29:02 -0800 [thread overview]
Message-ID: <20120203002902.GQ2518@linux.vnet.ibm.com> (raw)
In-Reply-To: <1328219944.2446.277.camel@twins>
On Thu, Feb 02, 2012 at 10:59:04PM +0100, Peter Zijlstra wrote:
> On Thu, 2012-02-02 at 15:43 -0500, Mikulas Patocka wrote:
> > Do you have some measurable use case where the user is removing block
> > devices so heavily that this causes a problem?
>
> Even one can be a problem, we're having people spend lots of time and
> effort to reduce machine wide jitter and interference. Adding it with
> such disregard isn't cool.
>
> There's no reason a management cpu adding or removing block devices
> should perturb the high-freq trading or industrial laser control running
> on the other side of the machine.
Very true for real-time applications!
For the heavy trading apps, given Frederic's upcoming user-mode-idle work,
I can keep this stuff from perturbing the apps. Still, batching would
be preferable.
Thanx, Paul
WARNING: multiple messages have this Message-ID (diff)
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Mikulas Patocka <mpatocka@redhat.com>,
axboe@kernel.dk, "Alasdair G. Kergon" <agk@redhat.com>,
dm-devel@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] backing-dev: use synchronize_rcu_expedited instead of synchronize_rcu
Date: Thu, 2 Feb 2012 16:29:02 -0800 [thread overview]
Message-ID: <20120203002902.GQ2518@linux.vnet.ibm.com> (raw)
In-Reply-To: <1328219944.2446.277.camel@twins>
On Thu, Feb 02, 2012 at 10:59:04PM +0100, Peter Zijlstra wrote:
> On Thu, 2012-02-02 at 15:43 -0500, Mikulas Patocka wrote:
> > Do you have some measurable use case where the user is removing block
> > devices so heavily that this causes a problem?
>
> Even one can be a problem, we're having people spend lots of time and
> effort to reduce machine wide jitter and interference. Adding it with
> such disregard isn't cool.
>
> There's no reason a management cpu adding or removing block devices
> should perturb the high-freq trading or industrial laser control running
> on the other side of the machine.
Very true for real-time applications!
For the heavy trading apps, given Frederic's upcoming user-mode-idle work,
I can keep this stuff from perturbing the apps. Still, batching would
be preferable.
Thanx, Paul
next prev parent reply other threads:[~2012-02-03 0:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-21 0:29 [PATCH] backing-dev: use synchronize_rcu_expedited instead of synchronize_rcu Mikulas Patocka
2011-07-21 7:27 ` Jens Axboe
2012-01-31 20:34 ` Peter Zijlstra
2012-01-31 21:04 ` Paul E. McKenney
2012-02-02 20:43 ` Mikulas Patocka
2012-02-02 21:59 ` Peter Zijlstra
2012-02-03 0:29 ` Paul E. McKenney [this message]
2012-02-03 0:29 ` 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=20120203002902.GQ2518@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=agk@redhat.com \
--cc=axboe@kernel.dk \
--cc=dm-devel@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mpatocka@redhat.com \
--cc=peterz@infradead.org \
/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.