public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Roger Larsson <roger.larsson@norran.net>
To: linux-kernel@vger.kernel.org
Subject: Re: Hard Hang with __alloc_pages: 0-order allocation failed (gfp=0x20/1) - Not out of memory
Date: Wed, 26 May 2004 21:58:30 +0200	[thread overview]
Message-ID: <200405262158.30747.roger.larsson@norran.net> (raw)
In-Reply-To: <200405260322.58571.roger.larsson@norran.net>

Modifying the header so you find it. And write a better summary...

* When you have little memory left __alloc_pages wont allow
   allocations from interrupt context (even if PF_MEMALLOC)

	if (current->flags & PF_MEMALLOC && !in_interrupt()) {

* But in the callchain there is a loop in __kmem_cache_alloc when running SMP

> 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;
>
> - - - snip - - -
> 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

But alloc_pages WILL fail every time... => infinite loop in interrupt
context... It probably should not try again in this case...

	if (!in_interrupt())
		goto try_again;

Or it should check if GFP_WAIT is set... A _busy_ wait is also a wait...

/RogerL

-- 
Roger Larsson
Skellefteå
Sweden

  reply	other threads:[~2004-05-26 20:04 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-26  1:22 (Found?) Re: Hard Hang with __alloc_pages: 0-order allocation failed (gfp=0x20/1) - Not out of memory Roger Larsson
2004-05-26 19:58 ` Roger Larsson [this message]
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
  -- strict thread matches above, loose matches on Subject: below --
2004-05-25 22:26 Hard Hang with __alloc_pages: 0-order allocation failed (gfp=0x20/1) - Not out of memory Doug Dumitru
2004-05-25 23:12 ` David S. Miller
2004-05-26 12:59   ` Marcelo Tosatti
2004-05-26 18:59     ` Doug Dumitru
2004-05-25 22:17 Doug Dumitru
2004-05-25 21:20 Feldman, Scott
2004-05-25 21:47 ` David S. Miller
2004-05-25 22:53   ` Marcelo Tosatti
2004-05-25 23:39     ` Marcelo Tosatti
2004-05-25 22:53 ` Marcelo Tosatti
2004-05-24  3:08 Doug Dumitru
2004-05-25 19:02 ` Marcelo Tosatti
2004-05-23 21:54 Doug Dumitru

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=200405262158.30747.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