On Thu, 2005-06-16 at 00:24, Andrew Morton wrote:
> Badari Pulavarty <pbadari@us.ibm.com> wrote:
> >
> > I sniff tested 2K lun support with 2.6.12-rc6-mm1 on
> >  my AMD64 box. I had to tweak qlogic driver and
> >  scsi_scan.c to see all the luns.
> > 
> >  (2.6.12-rc6 doesn't see all the LUNS due to max_lun
> >  issue - which is fixed in scsi-git tree).
> > 
> >  Test 1:
> >  	run dds on all 2048 "raw" devices - worked
> >  great. No issues.
> > 
> >  Tests 2: 
> >  	run "dds" on 2048 filesystems (one file
> >  per filesystem). Kind of works. I was expecting better
> >  responsiveness & stability.
> > 
> > 
> >  Overall - Good news is, it works. 
> > 
> >  Not so good news - with filesystem tests, machine becomes 
> >  unresponsive, lots of page allocation failures but machine 
> >  stays up and completes the tests and recovers.
> 
> Any chance of getting a peek at /proc/slabinfo?
> 
> Presumably increasing /proc/sys/vm/min_free_kbytes will help.
> 
> We seem to be always ooming when allocating scsi command structures. 
> Perhaps the block-level request structures are being allocated with
> __GFP_WAIT, but it's a bit odd.  Which I/O scheduler?  If cfq, does
> reducing /sys/block/*/queue/nr_requests help?

Yes. I am using CFQ scheduler. I changed nr_requests to 4 for all
my devices. I also changed "min_free_kbytes" to 64M.

Response time is still bad. Here is the vmstat, meminfo, slabinfo
and profle output. I am not sure why profile output shows 
default_idle(), when vmstat shows 100% CPU sys.

Thanks
Badari