[Top] [All Lists]

Re: %u-order allocation failed

To: Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
Subject: Re: %u-order allocation failed
From: Mikulas Patocka <mikulas@xxxxxxxxxxxxxxxxxxxxxxxx>
Date: Sun, 7 Oct 2001 14:28:17 +0200 (CEST)
Cc: Rik van Riel <riel@xxxxxxxxxxxxxxxx>, Krzysztof Rusocki <kszysiu@xxxxxxxxxxxxxxxxx>, linux-xfs@xxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx
In-reply-to: <E15qAQ3-0005Eq-00@xxxxxxxxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
On Sun, 7 Oct 2001, Alan Cox wrote:

> > Here goes the fix. (note that I didn't try to compile it so there may be
> > bugs, but you see the point). 
> It isnt a fix
> > kmalloc should be fixed too (used badly for example in select.c - and yes
> > - I have seen real world bugreports for poll randomly failing with
> > ENOMEM), but it will be hard to audit all drivers that they do not try to
> > use dma on kmallocated memory. 
> So you run out of blocks of vmalloc address space instead. The same problem
> still occurs and always will

I already said it in mail to Rik:

Yes - you can run out of vmalloc space. But you run out of it only when
you create too many processes (8192), load too many modules etc. If
someone needs to put such heavy load on linux, we can expect that he is
not a luser and he knows how to increase size of vmalloc space.

But - you run out of high-order pages randomly. You don't have to overflow
any resource - just map a file, touch it whole the first time and then
periodically touch every second page of it. Or: alloc periodically one
anon page and one cache page - read() (without readahead) does exactly

You can't run out of vmalloc space just by mapping files and touching

The probability math is fine - only if you are sure that pages are
allocated and freed randomly. But they are not. 


<Prev in Thread] Current Thread [Next in Thread>