From: "Luck, Tony" <tony.luck@intel.com>
To: linux-ia64@vger.kernel.org
Subject: RE: [Linux-ia64] SAL error record logging/decoding
Date: Wed, 21 May 2003 18:06:20 +0000 [thread overview]
Message-ID: <marc-linux-ia64-105590723705973@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-105590723705660@msgid-missing>
> From: Bjorn Helgaas [mailto:bjorn_helgaas@hp.com]
>
> I'd like to make some sort of forward progress on this issue
> before releasing a 2.4.21 ia64 patch. By default this will
> be to apply the original patch I posted on May 7.
>
> I'm not trying to railroad anything here, but 2.4.21 is
> getting close, and I'd rather not wait until 2.4.22. So
> if there are any major issues with the proposal, please
> raise them! The only real issue so far has been when
> the error records should cleared from the firmware log,
> and I'm certainly open to more discussion on that.
>
> As for 2.5, I'm willing to turn it into a filesystem if
> that's the Right Thing (though it feels like all the
> existing /proc/pal, /proc/sal, and /proc/efi stuff should
> be converted at the same time, which is more than I really
> had in mind). In any case, it will take me some time to
> learn about how that infrastructure works.
My only reservation with this is making sure that we deal
with error records in a rapid manner, so that a sequence
of errors occurring in quick succession have less chance
of overflowing the SAL log.
Is there any easy way to get a notification that there is
a record waiting in one of the /proc/sal/cpuX/* files ...
so that a daemon process can wake promptly to pick up the
error, log it, and issue the "clear" to free space for the
next error? Does /proc support a poll/select mechanism that
could be used here? Or perhaps there could be a top level
file /proc/sal/error which blocks on read from the daemon
and doesn't return until there's a record to be read? Maybe
the returned data from the read would be the cpu and error
class to tell the daemon which file to read?
Without some such method, the daemon needs to keep reading
all the /proc/sal/cpuX/* files at regular intervals. This
doesn't look like it scales well. A hypothetical 256 cpu
machine has 1024 such files that need to be checked, so even
with a poll interval of 10 seconds for each file, we'd need
to issue 102 reads per second from the daemon.
-Tony
next prev parent reply other threads:[~2003-05-21 18:06 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-07 23:41 [Linux-ia64] SAL error record logging/decoding Bjorn Helgaas
2003-05-08 0:05 ` David Mosberger
2003-05-08 0:13 ` Luck, Tony
2003-05-08 19:32 ` Bjorn Helgaas
2003-05-20 22:58 ` Bjorn Helgaas
2003-05-21 18:06 ` Luck, Tony [this message]
2003-05-21 20:48 ` Luck, Tony
2003-05-21 21:51 ` Luck, Tony
2003-05-22 21:29 ` Bjorn Helgaas
2003-05-23 0:24 ` Bjorn Helgaas
2003-05-23 15:42 ` Luck, Tony
2003-05-28 23:26 ` Bjorn Helgaas
2003-05-29 0:07 ` Keith Owens
2003-05-29 1:34 ` Bjorn Helgaas
2003-05-29 1:37 ` Keith Owens
2003-05-29 20:49 ` Luck, Tony
2003-05-29 21:31 ` Bjorn Helgaas
2003-05-29 21:47 ` Luck, Tony
2003-05-29 22:38 ` Bjorn Helgaas
2003-05-29 23:33 ` Luck, Tony
2003-05-30 11:56 ` Matthew Wilcox
2003-05-30 20:27 ` Bjorn Helgaas
2003-05-30 20:31 ` Bjorn Helgaas
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=marc-linux-ia64-105590723705973@msgid-missing \
--to=tony.luck@intel.com \
--cc=linux-ia64@vger.kernel.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