Re: [BUGFIX -v7] x86, MCE: Fix bugs and issues of MCE log ring buffer

[Hidetoshi Seto]

Frédéric Weisbecker wrote:
> Looks like the conversion of MCE log into a TRACE_EVENT is still in
> discussion whereas the current issues are urgent.
> 
> So the need is to have a more stable ring buffer. But this one is an ad-hoc one.
> We already have a general purpose per-cpu/lockless ring buffer implementation in
> kernel/trace/ring_buffer.c
> And it's not only used by tracing, it's generally available.

Thank you for this comment.

First of all, we have to make it clear that what is the urgent issue.
IMHO there are 2 issues, one is "small buffer" and the other is "non
ring buffer."

I think that the "small buffer" is definitely a scalability issue and
that this problem should be fixed asap to support large servers with
modern processors.
But I think that the "non ring buffer" is kind of a performance issue,
which is relatively minor problem on the MCE codes.

So frankly I approve of the per-CPU buffering, but be skeptical about
the ring buffering here.

In other words I don't mind dropping 9/10 of my patch set to postpone
converting the buffer to ring buffer, because even though the rests of
my patch set can convert the buffer to per-CPU style, which will solve
the urgent issue I have now.  That is why I divided original patch into
these pieces and made separate steps in the buffer conversion.

How about converting the MCE buffer to per-CPU as the 1st step, to solve
an urgent scalability issue, x86 maintainers? > Ingo, Peter?


> I think it would be nicer to use it to avoid a proliferation of
> unstable ring buffers inside the kernel.

I tend to agree with Andi.
I think the generic ring buffer implementation is too rich for current
use in MCE codes.

Maybe I could invent an alternative patch of my patch 9/10 to use generic
ring buffer from MCE codes.  But as I mentioned above I think that the
patch will solve the minor issue only.  Also I think that it might bring
unexpected impacts on traditional interfaces.
Therefore if there are still "use generic one if you want to use ring buffer"
comments then I'd like to drop 9/10 simply rather than reinvent it.

Any other suggestions?


BTW, I'd like to make it clear that what is the main complaint here.

Is it kind of "don't duplicate codes"?
The requirement in MCE codes is quite simple, so use of relatively complex
generic ring buffer doesn't fit for it.  I'm not sure but as Andi proposed
the next version of kernel/kfifo will be better choice here.  I can wait
the release of new kfifo either without making MCE log buffer to ring,
or with the temporary ad-hoc one.

Is it kind of "provide generic interface"?
I think it makes a lot of sense.  I can't say the /dev/mcelog is the best
interface for MCE logging.  Moreover there are many other hardware error
sources in a system such as PCIe and power unit etc., so it would be nice
for monitoring applications if kernel can provide a single channel (other
than /var/log/messages) to gather all kind of hardware errors.
The TRACE_EVENT would be one of possible options (or parts) to implement
such feature.

Oh, don't forget "please keep traditional interfaces."
To be honest I think the current interfaces look quite ugly.  But I know
that there are few real users such as mcelog (and mced?), and that at this
time we have no choice but use these tools.  So we cannot cast away current
interfaces immediately, until new interfaces are invented and new user land
application can provide enough functionalities.  Or we need to improve
current interface gradually and synchronously with improvements on tools ...
but I suppose in this way there will never be drastic changes.


Well, then I think what we have to do is invent a competitive new interface
for MCE logging, which can live together with current interface for a while,
isn't it?


Thanks,
H.Seto

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/