lkml.org 
[lkml]   [1999]   [Mar]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: vfork: out of memory, when there's plenty of swap free


On Sun, 14 Mar 1999, Andrea Arcangeli wrote:

> On Sat, 13 Mar 1999, Alan Cox wrote:
>
> >> run make -j and watch. Peak swap usage gets to 50Meg or so, then it
> >> starts dying with vfork: out of memory. [Can someone reproduce these,
> >> please?]
> >
> >Yes I can reproduce the running out of 8K block problem easily. Its the
> >lack of a memory defragmentation goal in the current 2.2 vm
>
> It's not the lack of defragmentation but due bad allocation of memory.
> Just to make an example look at the inode cache. It uses a _bad_ way to
> alloc memory. That's the _best_ way to generate _persistent_ fragmentation
> all over the place.

Nothing is bad there, except your diagnostic, in my opinion.
We just succeed 2 PAGES allocations mostly each time, but we want to
succeed such a allocation most of the time. ;)

Relying on 2 PAGES allocations _is_ broken. You can invent any prothesis
you want, a single butterfly that does not behave as you believe all
bufferflies should behave can defeat it, in my opinion that is not going
to change on this topic.

If the mess-up (i.e. enthropie) gets to high, you have every chance to get
defeated regardless the heuristic you implement, in my opinion. Lots of
things, including user-land applications may have patterns that will
increase the enthropie. Even an apparently kind change in the kernel may
have the offending effect to increase the mess-up.

If you want 2 PAGES allocations to succeed, pool such objects and wait for
availability each time nothing is available (hopefully, it will not last
too long :-) ). For the kernel stack, such a pool will probably work quite
bad.
Btw, I donnot want to rely on 2 PAGES allocations having to succeed most
of the time.

> And btw I think that for vmlloced areas would be possible to defrag them
> at runtime, but for normal __get_free_pages memory it's not possible, it's
> the allocation in first place that has to be smart to avoid fragmentation
> according to me.

If you lose one arm and you replace it by one of your legs, you probably
will not be quite happy of the result. :)
Better to do nothing than to do things that makes things worse, IMO.

The only smart allocation pattern we must rely on is to only require 1
PAGE allocation to succeed.
There is another smart allocation pattern that consists in allocating
nothing. ;-)

I donnot know any other allocation pattern that looks smart to me.

> Andrea Arcangeli

Regards,
Gérard.


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

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