lkml.org 
[lkml]   [2002]   [Feb]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [TEST] page tables filling non-highmem
    Date
    On February 18, 2002 01:27 pm, Andrea Arcangeli wrote:
    > Agreed, this is why I fighted with Linus and Marcelo trying to convince
    > them not to reintroduce the loop crap into the allocator that leads to
    > all sort of oom deadlocks because we lack the knowledge on the amount of
    > freeable pages (I even re-read the emails about such stuff in the thread
    > "VM tweaks" to be sure I was remembering right). OTOH, I really cannot
    > complain, they included so much stuff from my tree that even if we
    > disagreed on something at the end I don't mind :). And this is probably
    > also why I don't like very much to restart those threads about oom
    > deadlocks, I know my way is the only right way (i.e. non deadlock prone)
    > possible, and I live with it just fine.
    >
    > The only way we can learn if a page or a mapping is freeable or not, is
    > by trying to free it and by checking if we failed or not. We cannot know
    > in another manner, only checking the size of the caches or the amount of
    > the swap still unused is totally meaningless and broken. That's
    > unfortunate but that's how all linux kernels I know of works, and what I
    > did in my tree at the moment is the only possible way to avoid deadlocks
    > without having to do a major rework on the accounting side.

    Could you describe your page table deadlock-avoidance algorithm in more
    detail please?

    --
    Daniel
    -
    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 13:24    [W:3.131 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site