lkml.org 
[lkml]   [2005]   [Nov]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19

* Dave Hansen <haveblue@us.ibm.com> wrote:

> > then we need to see that 100% solution first - at least in terms of
> > conceptual steps.
>
> I don't think saying "truly 100%" really even makes sense. There will
> always be restrictions of some kind. For instance, with a 10MB kernel
> image, should you be able to shrink the memory in the system below
> 10MB? ;)

think of it in terms of filesystem shrinking: yes, obviously you cannot
shrink to below the allocated size, but no user expects to be able to do
it. But users would not accept filesystem shrinking failing for certain
file layouts. In that case we are better off with no ability to shrink:
it makes it clear that we have not solved the problem, yet.

so it's all about expectations: _could_ you reasonably remove a piece of
RAM? Customer will say: "I have stopped all nonessential services, and
free RAM is at 90%, still I cannot remove that piece of faulty RAM, fix
the kernel!". No reasonable customer will say: "True, I have all RAM
used up in mlock()ed sections, but i want to remove some RAM
nevertheless".

> There is also no precedent in existing UNIXes for a 100% solution.

does this have any relevance to the point, other than to prove that it's
a hard problem that we should not pretend to be able to solve, without
seeing a clear path towards a solution?

Ingo
-
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-01 16:03    [from the cache]
©2003-2011 Jasper Spaans