RE: XFS memory allocation deadlock in 2.6.38

From: Sean Noonan
Date: Mon Mar 28 2011 - 22:49:40 EST


> As it is, the question I'd really like answered is how a machine with
> 48GB RAM can possibly be short of memory when running mmap() on a
> 16GB file. The error that XFS is throwing indicates that the
> machine cannot allocate a single page of memory, so where has all
> your memory gone, and why hasn't the OOM killer been let off the
> leash? What is consuming the other 32GB of RAM or preventing it
> from being allocated?
Here's meminfo while a test was deadlocking. As you can see, we certainly aren't running out of RAM.
# cat /proc/meminfo
MemTotal: 49551548 kB
MemFree: 44139876 kB
Buffers: 5324 kB
Cached: 4970552 kB
SwapCached: 0 kB
Active: 52772 kB
Inactive: 4960624 kB
Active(anon): 37864 kB
Inactive(anon): 0 kB
Active(file): 14908 kB
Inactive(file): 4960624 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 4914084 kB
Writeback: 0 kB
AnonPages: 37636 kB
Mapped: 4925460 kB
Shmem: 280 kB
Slab: 223212 kB
SReclaimable: 176280 kB
SUnreclaim: 46932 kB
KernelStack: 3968 kB
PageTables: 35228 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 47073968 kB
Committed_AS: 86556 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 380892 kB
VmallocChunk: 34331773836 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 2048 kB
DirectMap2M: 2086912 kB
DirectMap1G: 48234496 kB


> Perhaps the output of xfs_bmap -vvp <file> after a successful vs
deadlocked run would be instructive....

I will try to get this tomorrow.

Sean
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/