[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.021 / U:12.624 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site