On Fri, 2006-01-20 at 19:17 -0600, James Bottomley wrote: > 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. > Just to mention, that 2.6.14.2 does not have this problem: vip ~ # cat /proc/slabinfo | grep scsi scsi_cmd_cache 60 60 384 10 1 : tunables 54 27 8 : slabdata 6 6 27 but my guess is that the problem may be not in SCSI, as not /and previosly actually/ I have this: vip ~ # cat /proc/slabinfo | grep reiser reiser_inode_cache 556594 556614 408 9 1 : tunables 54 27 8 : slabdata 61846 61846 0 which seems too high too - : 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
