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,
--
Jean Delvare
Suse L3
|