>>>> There is no special meaning for the pool size, if flutter of > 25 events, >>>> notify sas events will return error, and the further step work is >>>> depending on LLDD drivers. >>>> I hope libsas could do more work in this case, but now it seems a little >>>> difficult, this patch may be a interim fix, until we find a perfect >>>> solution. >>> >>> The principal of having a fixed-sized pool is ok, even though the pool size >>> needs more consideration. >>> >>> However my issue is how to handle pool exhaustion. For a start, relaying >>> info to the LLDD that the event notification failed is probably not the way >>> to go. I only now noticed "scsi: sas: scsi_queue_work can fail, so make >>> callers aware" made it into the kernel; as I mentioned in response to this >>> patch, the LLDD does not know how to handle this (and no LLDDs do actually >>> handle this). >>> >>> I would say it is better to shut down the PHY from libsas (As Dan mentioned >>> in the v1 series) when the pool exhausts, under the assumption that the PHY >>> has gone into some erroneous state. The user can later re-enable the PHY >>> from sysfs, if required. >> >> I considered this suggestion, and what I am worried about are, first if we >> disable phy once the sas event pool exhausts, it may hurt the pending sas >> event process which has been queued, > > I don't see how it affects currently queued events - they should just be > processed normally. As for LLDD reporting events when the pool is exhausted, > they are just lost.
So if we disable a phy, it's nothing affect to the already queued sas event process, which including access the phy to find target device ? > >> second, if phy was disabled, and no one trigger the reenable by sysfs, the >> LLDD has no way to post new sas phy events. > > For the extreme scenario of pool becoming exhausted and PHY being disabled, > it should remain disabled until user takes some action to fix originating > problem. So we should print explicit message to tell user what's happen and how to fix it. Thanks! Yijing. > >> >> Thanks! >> Yijing. >> >>> >>> Much appreciated, >>> John >>> >>>> >>>> Thanks! >>>> Yijing. >>>> >>>>> >>>>> Thanks, >>>>> John >>>>> >>>>> >>>>> . >>>>> >>>> >>>> >>>> . >>>> >>> >>> >>> >>> . >>> >> >> >> . >> > > > > . >
