lkml.org 
[lkml]   [2005]   [Nov]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19
Date
On Saturday 05 November 2005 19:30, Zan Lynx wrote:
> > None of this is very attractive.
>
> You could allow the 'hugetlb zone' to shrink, allowing more kernel
> allocations. User pages at the boundary would be moved to make room.

Please make that optional if you do. In my potential use case, an OOM kill
lets the administrator know they've got things configure wrong so they can
can fix it and try again. Containing and viciously reaping things like
dentries is the behavior I want out of it.

Also, if you do shrink the hugetlb zone it might be possible to
opportunistically expand it back to its original size. There's no guarantee
that a given kernel allocation will ever go away, but if it _does_ go away
then the hugetlb zone should be able to expand to the next blocking
allocation or the maximum size, whichever comes first. (Given that my
understanding of the layout may not match reality at all; don't ask me how
the discontiguous memory stuff would work in here...)

Rob
-
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-11-06 03:31    [W:0.504 / U:0.116 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site