Messages in this thread | | | Date | Tue, 12 Apr 2005 08:59:06 +1000 | From | Nick Piggin <> | Subject | Re: Processes stuck on D state on Dual Opteron |
| |
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.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |