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/
This archive was generated by hypermail 2b29 : Sat Feb 23 2002 - 21:00:13 EST