Re: [PATCH] New way of storing MCA/INIT logs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Mar 10, 2008 at 10:36:11AM +0100, Zoltan Menyhart wrote:
> Russ Anderson wrote:
> 
> >... in other implementations SAL knows of
> >the CPEI/CMCI and builds/buffers the records before the
> >SAL_GET_STATE_INFO() call.
> 
> If you mean MCAs corrected and transformed into CPEIs/CMCIs, I agree.
> If you mean the platform / CPU HW originated CPEIs/CMCIs, please
> explain how the SAL catches these interrupts.

The difference does not change how linux should handle CPEIs/CMCIs.

> I guess the differences among implementations call for a dynamically
> configurable solution.

I don't think so.  They should appear to linux the same.

> First I would have liked to discuss about the MCAs, which - in may
> approach - are completely separated from the CPEIs/CMCIs.
> As MCA log buffering cannot be synchronized as it is done
> for the CPEIs/CMCIs, it requires different code, can we discuss
> separately the mechanisms for MCAs and CPEIs/CMCIs?

Yes, I agree that different code for MCA/INIT and CPEI/CMCI is
the right approach.

> As far as the my MCA stuff is concerned, can you agree that it is
> safer than the original code?

Yes.  I like your approach.  I want to make sure it works
on larger systems.

> >>From a practical perspective, I don't think the difference significantly
> >changes how linux should handle CPEIs/CMCIs.  Linux should try to read/log
> >the CPEI/CMCI as quick as possible. The lack of SAL buffering increases
> >the chance of a record getting lost (overwritten) while SAL buffering
> >reduces the chance that a CPEI/CMCI record gets lost (overwritten).
> >If anything, the lack of SAL buffering would be a reason for more
> >linux buffers, to reduce the chance of losing records.
> 
> I agree.
> 
> >As stated above, from a practical perspective, I don't believe the
> >difference significanlty changes how linux should behave other than
> >possibly being a reason for more linux buffers.
> 
> >My preference is for a larger N.  Scaling N with system size
> >may be the best solution for small & large systems.
> 
> Can we think of some dynamic / platfom dependent way of configuring
> the number of the buffers?
> 
> E.g. my MCA stuff can start up with, say, 3 buffers by default,
> and you will be able to override it by a boot command line option.

How about having N be the number of actual cpus?  

-- 
Russ Anderson, OS RAS/Partitioning Project Lead  
SGI - Silicon Graphics Inc          rja@xxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel]     [Sparc Linux]     [DCCP]     [Linux ARM]     [Yosemite News]     [Linux SCSI]     [Linux x86_64]     [Linux for Ham Radio]

  Powered by Linux