Messages in this thread | | | Subject | Re: [PATCH 00/11] scsi: libsas: Remove in_interrupt() check | From | John Garry <> | Date | Mon, 11 Jan 2021 13:59:25 +0000 |
| |
On 11/01/2021 13:43, Ahmed S. Darwish wrote: > Hi John, Jason, > > On Tue, Dec 22, 2020 at 12:54:58PM +0000, John Garry wrote: >> On 22/12/2020 12:30, Jason Yan wrote: >>>> return event; >>>> >>>> >>>> So default for phy->ha->event_thres is 32, and I can't imagine that >>> The default value is 1024. >> Ah, 32 is the minimum allowed set via sysfs. >> >>>> anyone has ever reconfigured this via sysfs or even required a value >>>> that large. Maybe Jason (cc'ed) knows better. It's an arbitrary >>>> value to say that the PHY is malfunctioning. I do note that there is >>>> the circular path sas_alloc_event() -> sas_notify_phy_event() -> >>>> sas_alloc_event() there also. >>>> >>>> Anyway, if the 32x event memories were per-allocated, maybe there is >>>> a clean method to manage this memory, which even works in atomic >>>> context, so we could avoid this rework (ignoring the context bugs >>>> you reported for a moment). I do also note that the sas_event_cache >>>> size is not huge. >>>> >>> Pre-allocated memory is an option.(Which we have tried at the very >>> beginnig by Wang Yijing.) >> Right, I remember this, but I think the concern was having a proper method >> to manage this pre-allocated memory then. And same problem now. >> >>> Or directly use GFP_ATOMIC is maybe better than passing flags from lldds. >>> >> I think that if we don't really need this, then should not use it. >> > Kind reminder. Do we have any consensus here? >
Hi Ahmed,
To me, what you're doing seems fine.
I was looking for some API to manage small memory pools and which is atomic safe to avoid passing the context flag, but I didn't find such a thing.
Just one other thing to mention: I have a patch to remove the indirection in libsas notifiers: https://github.com/hisilicon/kernel-dev/commit/87fcd7e113dc05b7933260e7fa4588dc3730cc2a
I was going to send it today. Hopefully, if community has no problem with it, you can make your changes with that in mind.
Thanks, John
| |