From: Jean Delvare <jdelvare@suse.de>
To: xfs@oss.sgi.com
Subject: Memory allocation in xfs
Date: Mon, 22 Jan 2007 13:58:09 +0100 [thread overview]
Message-ID: <200701221358.09300.jdelvare@suse.de> (raw)
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
reply other threads:[~2007-01-22 13:15 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200701221358.09300.jdelvare@suse.de \
--to=jdelvare@suse.de \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox