lkml.org 
[lkml]   [2001]   [May]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCH] Re: Linux 2.4.4-ac10
On Thu, 24 May 2001, Rik van Riel wrote:

> > > > OK.. let's forget about throughput for a moment and consider
> > > > those annoying reports of 0 order allocations failing :)
> > >
> > > Those are ok. All failing 0 order allocations are either
> > > atomic allocations or GFP_BUFFER allocations. I guess we
> > > should just remove the printk() ;)
> >
> > Hmm. The guy who's box locks up on him after a burst of these
> > probably doesn't think these failures are very OK ;-) I don't
> > think order 0 failing is cool at all.. ever.
>
> You may not think it's cool, but it's needed in order to
> prevent deadlocks. Just because an allocation cannot do
> disk IO or sleep, that's no reason to loop around like
> crazy in __alloc_pages() and hang the machine ... ;)

True, but if we have resources available there's no excuse for a
failure. Well, yes there is. If the cost of that resource is
higher than the value of letting the allocation succeed. We have
no data on the value of success, but we do plan on consuming the
reclaimable pool and do that (must), so I still think turning
these resources loose at strategic moments is logically sound.
(doesn't mean there's not a better way.. it's just an easy way)

I'd really like someone who has this problem to try the patch to
see if it does help. I don't have this darn problem myself, so
I'm left holding a bag of idle curiosity. ;-)

Cheers,

-Mike

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:53    [W:0.049 / U:3.452 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site