On Fri, 2006-01-20 at 16:50 -0800, Andrew Morton wrote: > For linux-scsi reference, Chase's /proc/slabinfo says: > > scsi_cmd_cache 1547440 1547440 384 10 1 : tunables 54 27 8 : > slabdata 154744 154744 0 There's another curiosity about this: the linux command stack is pretty well counted per scsi device (it's how we control queue depth), so if a driver leaks commands we see it not by this type of behaviour, but by the system hanging (waiting for all the commands the mid-layer thinks are outstanding to return). So, the only way we could leak commands like this is in the mid-layer command return logic ... and I can't find anywhere this might happen. The sequence is: driver -> cmd->scsi_done() -> blk softirq -> scsi_softirq_done() -> scsi_finish_cmd() (where the queue counts are decremented, so anything after here could leak commands if the rest of the chain is broken) -> cmd->done() (which is the ULD completion callback) -> scsi_io_completion() (frees the sg table, so if the sgpool slabs aren't out of whack we must be past here) -> scsi_end_request() -> scsi_next_command() -> scsi_put_command() (which is where the command goes back to the slab). James > > Curious - the -s... were you expecting the ring buffer > > to exceed 16384? > > It can sometimes be quite large. I always say -s 1000000 to make sure > everything got there. > > > I don't think my (boot time) buffer does. > > It's compile-time configurable with CONFIG_LOG_BUF_SHIFT and boot-time > configurable with log_buf_len=n. > - > : 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 - : 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
