Re: OOM Killer killing whole system

[Anton Titov <a.titov@host.bg>]

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