From: Borislav Petkov <bp@amd64.org>
To: <linux-kernel@vger.kernel.org>
Subject: [RFC PATCH 00/21] RAS daemon prototype, v1
Date: Thu, 1 Jul 2010 17:55:42 +0200 [thread overview]
Message-ID: <1277999763-20357-1-git-send-email-bp@amd64.org> (raw)
From: Borislav Petkov <borislav.petkov@amd.com>
(resubmitting since lkml wasn't on CC list)
Hi guys,
here's the first rough version of all the jerky code that attempts to
implement a RAS daemon listening for MCEs using perf. This is a preview
code only, I still need to figure out how to do the sample parsing
the easiest and flesh out the daemon functionality a bit more. Also,
I wanted to reuse as much code as possible therefore a lot had to be
reengineered with the perf tool and all its library-like compilation
units.
With this, you can do
make perf
or
make ras
and build the respective tool.
Even though I tried to split the patchset for easier review, please bear
in mind that there are some fat guys there (241K is the biggest one).
However, they don't do anything special except moving code around. As
such, they might not appear on lkml due to vger size constraints so I've
upped the whole patchset also at
git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git perf-v1
The patchset is based on tip/perf/core from last week. Here are some
more details to some of the patches individually:
2: enables the mce tracepoint unconditionally. I had a problem with
perf_event_attr.sample_period which is checked in perf_swevent_add().
Currently, I'm setting it to ULLONG_MAX but this is icky. I'd much
rather have the check do something like
if (event->type != PERF_EVENT_TYPE_PERSISTENT)
if (!hwc->sample_period)
return;
or similar.
4: sys_perf_event_open needs to know about already allocated and
enabled events.
5-10: carves out a bunch of generic perf compilation units into a common
lib. Split into 5 patches for easier review.
12-14: those are pulled in when exporting parse_events.c for external use.
16: lib/perf/misc.c contains functions and global variables like
pager_in_use() or perf_guest or usage_with_options() which are used in
generic utilities but are strictly perf-specific. Long term we should
strive in making the library self-contained and getting rid of those.
19-20: those are only needed for testing, they'll go in over the edac
tree in the next merge window. Added for completeness here.
21: only bare-bones implementation, needs a lot of fleshing out
Anyways, please have a look and let me know either way :)
Thanks,
Boris.
next reply other threads:[~2010-07-01 15:54 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-01 15:55 Borislav Petkov [this message]
2010-07-01 15:55 ` [PATCH 01/21] perf_events: Export buffer handling functions Borislav Petkov
2010-07-01 15:55 ` [PATCH 02/21] mce: Add persistent events Borislav Petkov
2010-07-01 15:55 ` [PATCH 03/21] perf_events: Add a helper to search for an event in a context Borislav Petkov
2010-07-01 15:55 ` [PATCH 04/21] perf_events: Handle persistent events accordingly Borislav Petkov
2010-07-01 15:55 ` [PATCH 05/21] perf: rewire generic library stuff, p1 Borislav Petkov
2010-07-01 15:55 ` [PATCH 06/21] perf: rewire generic library stuff, p2 Borislav Petkov
2010-07-01 15:55 ` [PATCH 07/21] perf: rewire generic library stuff, p3 Borislav Petkov
2010-07-01 15:55 ` [PATCH 08/21] perf: rewire generic library stuff, p4 Borislav Petkov
2010-07-01 15:55 ` [PATCH 09/21] perf: rewire generic library stuff, p5 Borislav Petkov
2010-07-01 15:55 ` [PATCH 10/21] perf: rewire generic library stuff, p6 Borislav Petkov
2010-07-01 15:55 ` [PATCH 11/21] perf: Export /proc/mounts parser Borislav Petkov
2010-07-01 15:55 ` [PATCH 12/21] perf: Carve out perf bits for general usage, p1 Borislav Petkov
2010-07-01 15:55 ` [PATCH 13/21] perf: Carve out perf bits for general usage, p2 Borislav Petkov
2010-07-01 15:55 ` [PATCH 14/21] perf: Carve out perf bits for general usage, p3 Borislav Petkov
2010-07-01 15:55 ` [PATCH 15/21] perf: Export trace event utils Borislav Petkov
2010-07-06 22:18 ` Steven Rostedt
2010-07-07 7:57 ` Borislav Petkov
2010-07-01 15:55 ` [PATCH 16/21] perf: Add a common misc.c compilation unit Borislav Petkov
2010-07-01 15:55 ` [PATCH 17/21] perf: Carve out mmap helpers for general use Borislav Petkov
2010-07-01 15:56 ` [PATCH 18/21] perf: Split build-id.c Borislav Petkov
2010-07-01 15:56 ` [PATCH 19/21] x86, mce: Notify about corrected events too Borislav Petkov
2010-07-01 15:56 ` [PATCH 20/21] amd64_edac: Remove polling mechanism Borislav Petkov
2010-07-01 15:56 ` [PATCH 21/21] tools, ras: Add a RAS daemon Borislav Petkov
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=1277999763-20357-1-git-send-email-bp@amd64.org \
--to=bp@amd64.org \
--cc=linux-kernel@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
Powered by JetHome