mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

             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®