From: "David S. Miller" <davem@redhat.com>
To: Linus Torvalds <torvalds@osdl.org>
Cc: ak@suse.de, willy@debian.org, ishii.hironobu@jp.fujitsu.com,
linux-kernel@vger.kernel.org, linux-ia64@vger.kernel.org
Subject: Re: [RFC/PATCH, 2/4] readX_check() performance evaluation
Date: Wed, 28 Jan 2004 14:15:24 -0800 [thread overview]
Message-ID: <20040128141524.5922fe67.davem@redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.58.0401281340301.28145@home.osdl.org>
On Wed, 28 Jan 2004 13:43:54 -0800 (PST)
Linus Torvalds <torvalds@osdl.org> wrote:
> On Wed, 28 Jan 2004, Andi Kleen wrote:
> >
> > On Wed, 28 Jan 2004 12:28:56 -0800 (PST)
> > Linus Torvalds <torvalds@osdl.org> wrote:
> >
> > >
> > > Alternatively, if you get a lot of information at MCE time (CPU that did
> > > the access + some device data), just queue up the information in a per-CPU
> > > queue. You don't have to worry about overflow - you can just drop if if
> >
> > That assumes that the access happened with preempt off ?
>
> Yes. I assume you want _some_ locking anyway, at least within that
> particular device driver (you don't want to have an irq handler touch the
> device at the same time you are doing this thing), so any such spinlock
> would have disabled preemption anyway.
I am rather certain you are going to need to do a per-controller lock
the driver will need to grab during such sequences. It is the only way
I can see, if the state sits in some controller register or resetting
that status must be done in the controller, to keep two driver inits
or resets or whatever from bumping into each other.
next prev parent reply other threads:[~2004-01-28 22:15 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-28 1:54 [RFC/PATCH, 2/4] readX_check() performance evaluation Hironobu Ishii
2004-01-28 2:55 ` Linus Torvalds
2004-01-28 4:44 ` Paul Mackerras
2004-01-28 8:58 ` Russell King
2004-01-28 16:15 ` Linus Torvalds
2004-01-28 17:01 ` Grant Grundler
2004-01-28 18:20 ` Matthew Wilcox
2004-01-28 19:19 ` Andi Kleen
2004-01-28 19:33 ` Linus Torvalds
2004-01-28 19:40 ` Andi Kleen
2004-01-28 20:06 ` Linus Torvalds
2004-01-28 20:15 ` Andi Kleen
2004-01-28 20:19 ` [RFC/PATCH, 2/4] readX_check() performance evaluation II Andi Kleen
2004-01-28 20:28 ` [RFC/PATCH, 2/4] readX_check() performance evaluation Linus Torvalds
2004-01-28 20:30 ` Linus Torvalds
2004-01-28 21:09 ` Andi Kleen
2004-01-28 21:43 ` Linus Torvalds
2004-01-28 21:52 ` Andi Kleen
2004-01-28 22:21 ` Linus Torvalds
2004-01-28 22:39 ` Andi Kleen
2004-01-28 22:59 ` Linus Torvalds
2004-01-29 12:24 ` Hironobu Ishii
2004-01-28 22:15 ` David S. Miller [this message]
2004-01-28 3:09 ` Matthew Wilcox
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=20040128141524.5922fe67.davem@redhat.com \
--to=davem@redhat.com \
--cc=ak@suse.de \
--cc=ishii.hironobu@jp.fujitsu.com \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.org \
--cc=willy@debian.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox