On Thu, Oct 13, 2011 at 4:51 PM, Nicholas A. Bellinger <nab@xxxxxxxxxxxxxxx> wrote: > On Wed, 2011-10-12 at 11:17 -0400, Christoph Hellwig wrote: >> Warning: I'm not actually able to reproduce QUEUE FULL handling locally, >> so the actual code path touched here isn't tested. >> >> If there actually is a good reason for doing the workqueue step in >> queue full handling this is obviously not going to fly, but even after >> an extensive audit I really can't see anything that requires us to not >> call transport_add_cmd_to_queue from the original context. >> > > Mmmmm, i'm still undecided on this one. The thought here is having a > workqueue + context switch for a QUEUE FULL event gives the hardware > (more) time to make room by clearing entries in it's request/response > queues, and by re-adding these immediately would end up generating more > QUEUE FULL events. > > I don't know how much (more) time the HW needs under load to avoid > excessive QUEUE FULL events, so i'll probably pass merging this one for > the moment until there is a better idea of potential drawbacks here. I agree it doesn't really make sense to immediately requeue a request that you didn't have room for in your queue a moment ago. Really it seems we should pause processing until we have something complete and make room in the queue again. Not sure how to fit that into the overal target architecture. - R. -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
