Re: Processes stuck on D state on Dual Opteron

[Nick Piggin <nickpiggin@yahoo.com.au>]

Claudio Martins wrote:

>    Right. I'm using two Seagate ATA133 disks (ide controler is AMD-8111) each 
> with 4 partitions, so I get 4 md Raid1 devices. The first one, md0, is for 
> swap. The rest are
> 
> ~$ df -h
> Filesystem            Size  Used Avail Use% Mounted on
> /dev/md1              4.6G  1.9G  2.6G  42% /
> tmpfs                1005M     0 1005M   0% /dev/shm
> /dev/md3               32G  107M   30G   1% /home
> /dev/md2               31G  149M   29G   1% /var
> 
>   In these tests, /home on md3 is the working area for stress.
> 
>   The io scheduler used is the anticipatory. 
> 

OK.

> 
>   OK, I'll try them in a few minutes and report back.
>  

I'm not overly hopeful. If they fix the problem, then it's likely
that the real bug is hidden.

>   I'm curious as whether increasing the vm.min_free_kbytes sysctl value would 
> help or not in this case. But I guess it wouldn't since there is already some 
> free memory and also the alloc failures are order 0, right?
> 

Yes. And the failures you were seeing with my first patch were coming
from the mempool code anyway. We want those to fail early so they don't
eat into the min_free_kbytes memory.

You could try raising min_free_kbytes though. If that fixes it, then it
indicates there might be some problem in a memory allocation failure
path in software raid somewhere.

Thanks

-- 
SUSE Labs, Novell Inc.