On 03/22/06 21:54, Gavin Maltby wrote:
On 03/20/06 19:09, [EMAIL PROTECTED] wrote:
FMA looks like it's about 100k/cpu (ERPT_MAX_ERRS * max_ncpu *
ERPT_DATA_SZ)
And they are all preallocated? Sounds like a bug to me.
Yes they are, so that we can fill error reports from any context
without worrying sbout kmem allocation, pil level, locks etc.
I answered too soon here. As luck would have it I have hit a problem
today with the default ERPT_DATA_SZ :-)
For each of the non-nvlist errorqs we allocate a bunch of elements, but
they are all pretty small.
For the ereport_errorq, which has a special purpose in life of arranging
for in-transit ereports to be written out to the dump device during a panic
for replay during boot, we have:
#define ERPT_MAX_ERRS 32
#define ERPT_DATA_SZ (3 * 1024)
if (ereport_qlen == 0)
ereport_qlen = ERPT_MAX_ERRS * MAX(max_ncpus, 4);
if (ereport_size == 0)
ereport_size = ERPT_DATA_SZ;
On x86 with max_ncpus of 21 (and which is not resized during boot)
that accounts for an allocation of 32 * 3 * 1024 * 21 = 2064384 bytes
plus some trivial additional overhead, or around 2MB.
It's only the "vital" errorqs that fill the above one during panic -
reports of uncorrectable errors. I've never seen anywhere near
32 uncorrectables striking a single cpu at a time - < 5 is more
more like it. And I may need to increase ERPT_DATA_SZ above,
so it may be time to revisit this computation.
Cheers
Gavin
_______________________________________________
opensolaris-discuss mailing list
[email protected]
