On 12/08/2017 10:42 AM, Jason Yan wrote: > If the PHY burst too many events, we will alloc a lot of events for the > worker. This may leads to memory exhaustion. > > Dan Williams suggested to shut down the PHY if the events reached the > threshold, because in this case the PHY may have gone into some > erroneous state. Users can re-enable the PHY by sysfs if they want. > > We cannot use the fixed memory pool because if we run out of events, the > shut down event and loss of signal event will lost too. The events still > need to be allocated and processed in this case. > > Suggested-by: Dan Williams <dan.j.williams@xxxxxxxxx> > Signed-off-by: Jason Yan <yanaijie@xxxxxxxxxx> > CC: John Garry <john.garry@xxxxxxxxxx> > CC: Johannes Thumshirn <jthumshirn@xxxxxxx> > CC: Ewan Milne <emilne@xxxxxxxxxx> > CC: Christoph Hellwig <hch@xxxxxx> > CC: Tomas Henzl <thenzl@xxxxxxxxxx> > --- > drivers/scsi/libsas/sas_init.c | 33 ++++++++++++++++++++++++++++++++- > drivers/scsi/libsas/sas_phy.c | 27 ++++++++++++++++++++++++++- > include/scsi/libsas.h | 6 ++++++ > 3 files changed, 64 insertions(+), 2 deletions(-) > Well, this still looks a bit error prone; what if the system runs out of memory before the pool is exhausted? (Also a threshold of 1024 events is a bit arbitrary; one might want to adjust that). Couldn't you allocate two static events always (for shutdown and signal loss), and then use a fixed pool? Cheers, Hannes -- Dr. Hannes Reinecke Teamlead Storage & Networking hare@xxxxxxx +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg)
