Moore, Eric wrote: > On Wednesday, June 14, 2006 1:00 PM, Mike Reed wrote: >> James Bottomley wrote: >>> I was still thinking of something that made mpt_config() >> never return >>> -EAGAIN. How does the following work out? It's my first pass at >>> sorting out the frame and active logic in mptbase: > ...snip... > >> Another comment, for every i/o, this patch introduces overhead. >> spinlock and checking a list which is empty 99.99[...]% of the time. >> I'll have to perform an iop measurement to see if there is a >> measurable impact on system performance. >> > > What overhead? We don't read config pages on every I/O. James > patch only effects the reading of config pages when there is > a host reset. I think you're mistaken about James' patch. Doesn't every i/o use a message frame? James' patch to sleep on frame exhaustion requires a wakeup every time a msg frame is released, which is performed at the end of mpt_put_msg_frame(). Am I missing something? > > One concern on this patch. A possible deadlock situation could > occur if we run out of message frames. Meaning there is another way > that mpt_get_msg_frame() could return NULL, and that is becuase > the ioc->FreeQ list is empty. This patch only addresses the case > when there is a host reset. Utimatley we need to address both > cases when NULL is returned. Id rather try to come up with a > solution where the fix is isolated inside of mpt_get_msg_frame(). James' code handles both frame exhaustion and ioc->active == 0. But, the only caller to mpt_get_msg_frame() that now sleeps is mpt_config(). Mike > > Eric Moore > - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
