On 2011-09-13 18:46, Eric Seppanen wrote: > On Tue, Sep 13, 2011 at 5:49 AM, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: >> Btw, there is another _huge_ issue with the driver, and that is the >> lack of any internal queueing. Remember the make_request interface is >> an extremly thin layer (or rather the lack of it) below the filesystem. >> >> So for example if eh_active is non-zero you return -EBUSY to the >> filesystems. That's an error code it a) doesn't recognize and b) >> couldn't handle even if it did. Similarly mtip_hw_get_scatterlist >> simply blocks if no tag is currently available instead of queueing >> it up. > > Just out of curiosity, why is blocking on no-tag-available a bad > thing? How is it any different than the blocking that will occur when > a request queue is full? When the hardware queue depth is bigger than > that of a request queue, what extra benefit does queuing give? The blocking for a free tag is fine, the actual implementation is definitely not optimal (using a rw semaphore with count initialized to the tag depth, ugh). You'll need to block for a free tag in any case, or add a thread to restart things on a free tag. The thread would not help performance. But the -EBUSY is definitely a bug, that needs to be a waiting condition as well. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
