Memory allocation in xfs
Hi all,
While investigating a customer-reported issue, I noticed the following code in the xfs filesystem (in linux/fs/xfs/linux-2.6/kmem.c):
#define MAX_VMALLOCS 6
#define MAX_SLAB_SIZE 0x20000
void *kmem_alloc(size_t size, int flags)
{
int retries = 0;
int lflags = kmem_flags_convert(flags);
void *ptr;
do {
if (size < MAX_SLAB_SIZE || retries > MAX_VMALLOCS)
ptr = kmalloc(size, lflags);
else
ptr = __vmalloc(size, lflags, PAGE_KERNEL);
if (ptr || (flags & (KM_MAYFAIL|KM_NOSLEEP)))
return ptr;
if (!(++retries % 100))
printk(KERN_ERR "XFS: possible memory allocation "
"deadlock in %s (mode:0x%x)\n",
__FUNCTION__, lflags);
blk_congestion_wait(WRITE, HZ/50);
} while (1);
}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. I read in LDD3 that some architectures have a relatively small address space reserved for vmalloc, I guess this explains why this fallback was implemented. Am I correct? I wonder if it's really a good idea to then insist on kmalloc if kmalloc fails too, but at this point it probably no longer matters, we're doomed...
What I am curious about is why the fallback in the other direction wasn't implemented. If we need an amount of memory less than 128 kB and kmalloc keeps failing, isn't it worth trying vmalloc? Disclaimer: I am just trying to learn how the memory management works in Linux 2.6, so I might as well be totally wrong.
Thanks,
Signature · 2 lines
Jean Delvare Suse L3