[lkml]   [2001]   [Oct]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: %u-order allocation failed
> > It is perfectly OK to have a bit slower access to task_struct with
> > probability 1/1000000.
> Except that you added a bug where some old driver code would crash the
> machine by doing so.


> > Yes, but there are still other dangerous usages of kmalloc and
> > __get_free_pages. (The most offending one is in select.c)
> Nothing dangeorus there. The -ac vm isnt triggering these cases.

Sorry, but it can be triggered by _ANY_ VM since buddy allocator was
introduced. You have no guarantee, that you find two or more consecutive
free pages. And if you don't, poll() fails.

> > not abort his operation when it happens. Instead - they are trying to make
> > high-order allocations fail less often :-/ How should random
> > Joe-driver-developer know, that kmalloc(4096) is safe and kmalloc(4097) is
> > not?
> 4096 is not safe - there is no safe size for a kmalloc, you can always run
> out of memory - deal with it.

This is not about running out of memory. It is about free space
fragmentation. Think this:

You have no swap.
Program allocates one file cache page, one anon page, one cache page, one
anon page and so on. The memory will look like:

cache page
anon page
cache page
anon page
cache page
anon page

Now some driver wants to allocate 4097 and it CAN'T. Even when there's
half memory free.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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