From: Roger Larsson <roger.larsson@norran.net>
To: linux-kernel@vger.kernel.org
Subject: (Found?) Re: Hard Hang with __alloc_pages: 0-order allocation failed (gfp=0x20/1) - Not out of memory
Date: Wed, 26 May 2004 03:22:58 +0200 [thread overview]
Message-ID: <200405260322.58571.roger.larsson@norran.net> (raw)
Hi,
Since I read linux-kernel via achieves, this might be found already - but
anyway... (CONFIG_SMP problem? Oh, noticed that this is 2.4.21...)
decode "(gfp=0x20/1)" and you find that
current->flags is PF_MEMALLOC
gfp is __GFP_HIGH (== GFP_ATOMIC)
and the backtrace says we are in_interrupt()
So I guess this is the key line...
if (current->flags & PF_MEMALLOC && !in_interrupt()) {
* Less than (.min >> 2) of memory left.
* In interrupt
=> Not allowed to allocate anything more
Does the caller understand that repeating requests will not help?
In e1000_main.c
skb = dev_alloc_skb(adapter->rx_buffer_len + reserve_len);
___skbuff.h___
static inline struct sk_buff *dev_alloc_skb(unsigned int length)
{
return __dev_alloc_skb(length, GFP_ATOMIC);
}
static inline struct sk_buff *__dev_alloc_skb(unsigned int length,
int gfp_mask)
{
struct sk_buff *skb;
skb = alloc_skb(length+16, gfp_mask);
if (skb)
skb_reserve(skb,16);
return skb;
}
And the rather big alloc_skb calls kmalloc
void * kmalloc (size_t size, int flags)
{
cache_sizes_t *csizep = cache_sizes;
for (; csizep->cs_size; csizep++) {
if (size > csizep->cs_size)
continue;
return __kmem_cache_alloc(flags & GFP_DMA ?
csizep->cs_dmacachep : csizep->cs_cachep, flags);
}
return NULL;
}
- - - now take a close look at the try_again path - - -
static inline void * __kmem_cache_alloc (kmem_cache_t *cachep, int flags)
{
unsigned long save_flags;
void* objp;
kmem_cache_alloc_head(cachep, flags);
try_again:
local_irq_save(save_flags);
#ifdef CONFIG_SMP
{
cpucache_t *cc = cc_data(cachep);
if (cc) {
if (cc->avail) {
STATS_INC_ALLOCHIT(cachep);
objp = cc_entry(cc)[--cc->avail];
} else {
STATS_INC_ALLOCMISS(cachep);
objp = kmem_cache_alloc_batch(cachep,cc,flags);
if (!objp)
goto alloc_new_slab_nolock;
- - -
alloc_new_slab_nolock:
#endif
local_irq_restore(save_flags);
if (kmem_cache_grow(cachep, flags))
/* Someone may have stolen our objs. Doesn't matter, we'll
* just come back here again.
*/
goto try_again;
But kmem_cache_grow will return failed...
-> kmem_getpages -> _get_free_pages -> alloc_pages
Or have I missed something?
/RogerL
--
Roger Larsson
Skellefteå
Sweden
next reply other threads:[~2004-05-26 1:28 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-26 1:22 Roger Larsson [this message]
2004-05-26 19:58 ` Roger Larsson
2004-05-26 20:27 ` PROBLEM: e100 or e1000 on SMP kernel freeze system (ipx+ncp) Roger Larsson
2004-05-26 22:47 ` Andrew Shirrayev
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=200405260322.58571.roger.larsson@norran.net \
--to=roger.larsson@norran.net \
--cc=linux-kernel@vger.kernel.org \
/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
all inboxes | Powered by JetHome®