lkml.org 
[lkml]   [2005]   [Jan]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] per thread page reservation patch
Nikita Danilov <nikita@clusterfs.com> wrote:
>
> >
> > Why does the filesystem risk going oom during the rebalance anyway? Is it
> > doing atomic allocations?
>
> No, just __alloc_pages(GFP_KERNEL, 0, ...) returns NULL. When this
> happens, the only thing balancing can do is to panic.

__alloc_pages(GFP_KERNEL, ...) doesn't return NULL. It'll either succeed
or never return ;) That behaviour may change at any time of course, but it
does make me wonder why we're bothering with this at all. Maybe it's
because of the possibility of a GFP_IO failure under your feet or
something?

What happens if reiser4 simply doesn't use this code?


If we introduce this mechanism, people will end up using it all over the
place. Probably we could remove radix_tree_preload(), which is the only
similar code I can I can immediately think of.

Page reservation is not a bad thing per-se, but it does need serious
thought.

How does reiser4 end up deciding how many pages to reserve? Gross
overkill?
-
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 14:09    [W:0.084 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site