Anton Titov <[email protected]> wrote:
>
> 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
Having large numbers of cached inodes is fairly common. Try running
something which uses lots of memory: memset(malloc(gigabytes)), or usemem
from http://www.zip.com.au/~akpm/linux/patches/stuff/ext3-tools.tar.gz or
read a multi-gigabyte file from disk and you shuld see the inode count wind
down.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
