[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100614144403.GA369@basil.fritz.box>
Date: Mon, 14 Jun 2010 16:44:03 +0200
From: Andi Kleen <andi@...stfloor.org>
To: Don Zickus <dzickus@...hat.com>
Cc: Hidetoshi Seto <seto.hidetoshi@...fujitsu.com>,
Ingo Molnar <mingo@...e.hu>, Huang Ying <ying.huang@...el.com>,
Fr??d??ric Weisbecker <fweisbec@...il.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
"H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org,
Andi Kleen <andi@...stfloor.org>
Subject: Re: [RFC 1/3] Unified NMI delayed call mechanism
> I think the perf event subsytem can log events in NMI context already and
> deliver them to userspace when the NMI is done. This is why I think Ingo
> wants MCE to be updated to sit on top of the perf event subsytem to avoid
> re-invent everything again.
perf is not solving the problem this is trying to solve.
> Then again I do not know enough about the MCE stuff to understand what you
> mean when an event comes in but you can't handle it in an NMI-safe
> context. An example would be helpful.
At least for MCE hwpoison recovery needs to sleep and you obviously cannot sleep in
NMI like context. The way it's done is to first do a self interrupt, then do a work queue
wakeup and finally the sleeping operations.
perf does not fit into this because it has no way to process such an event
inside the kernel.
Anyways this just cleans up the existing mechanism to share some code.
-Andi
--
ak@...ux.intel.com -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists