memory allocation in xfs
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): 1169416074.18017.54.camel@edge
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 38 lines · Jean Delvare
Hi Nathan,
Quoted 5 lines · Nathan Scott
Quoted 2 lines · Jean Delvare
While investigating Suse bug #177066, I noticed the following code in the xfs filesystem (in
linux/fs/xfs/linux-2.6/kmem.c):Sorry for the delay, I've been at LCA the last week or so.
Heh, no worry :-)
Quoted 11 lines
Quoted 10 lines
If I read it correctly, it first chooses between kmalloc and vmalloc based on size, picking kmalloc if the size is less than 128 kB, and vmalloc if it's larger. So far, so good, makes sense to me.
Then, if 6 attempts at vmalloc failed, it switches to kmalloc regardless of the size. That's what I don't understand. I am not a kernel memory management guru, in fact I'm just trying to learn how these things work, but isn't kmalloc _less_ likely to succeed than vmalloc for a large size, given that kmalloc must find a physical block of that size, while vmalloc only needs a virtual one?
Quoted 9 lines
I'm also not a VM guru, and implemented here based on others advice; as I understand things, vmalloc space on some platforms can become quite easily depleted such that we can get into the situation that all of vmalloc space is allocated and cannot be released - whereas for kmalloc space there is a chance that some other part of the kernel will free things up and allow us to make a large allocation. You might be able to get more information by following up to the XFS list, as the people who were reviewing my changes and suggested this change, will be there.
Correct, I read about the limited vmalloc space in LDD3 too. The book says it's "relatively small" on "some architectures" but doesn't give details. I ended up testing on my i386 and
x86_64systems and I found 631 MB and 32 TB, respectively, which I don't think qualify as small. So I guess the "relatively small" was referring to other architectures.
Quoted 7 lines
Anyway, it makes some sense to try
kmalloc()ifvmalloc()fails 6 times, after all there's nothing to lose. But I wonder if it really makes sense to insist onkmalloc()ifkmalloc()is failing too. And I wonder why the other fallback (fromkmalloc()tovmalloc()) wasn't implemented. But I also agree that we are in trouble if the allocations start failing, and the solution it to make sure xfs isn't asking for unreasonably large amounts of memory (which I am aware has been addressed since.)
*nod* ... it is largely academic now, there are very few places where we will ask for large memory allocations anymore (Mandy fixed by far the worst offender with the incore extent changes), and IIRC the only places where we now attempt large allocations (other than debug/trace allocs) are in places where we allow an allocation failure and can fall back to allocating in smaller sizes.
cheers.
Signature · 1 line
Nathan