Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19

From: Gerrit Huizenga (gh_at_us.ibm.com)
Date: 11/02/05

  • Next message: Arkadiusz Miskiewicz: "mxser driver in 2.6.14: kernel BUG at drivers/char/mxser.c:1004!" 
    To: Ingo Molnar <mingo@elte.hu>
Date:	Wed, 02 Nov 2005 07:02:23 -0800

    On Wed, 02 Nov 2005 13:00:48 +0100, Ingo Molnar wrote:
    >
    > * Gerrit Huizenga <gh@us.ibm.com> wrote:
    >
    > >
    > > On Wed, 02 Nov 2005 11:41:31 +0100, Ingo Molnar wrote:
    > > >
    > > > * Gerrit Huizenga <gh@us.ibm.com> wrote:
    > > >
    > > > > > generic unpluggable kernel RAM _will not work_.
    > > > >
    > > > > Actually, it will. Well, depending on terminology.
    > > >
    > > > 'generic unpluggable kernel RAM' means what it says: any RAM seen by the
    > > > kernel can be unplugged, always. (as long as the unplug request is
    > > > reasonable and there is enough free space to migrate in-use pages to).
    > >
    > > Okay, I understand your terminology. Yes, I can not point to any
    > > particular piece of memory and say "I want *that* one" and have that
    > > request succeed. However, I can say "find me 50 chunks of memory
    > > of your choosing" and have a very good chance of finding enough
    > > memory to satisfy my request.
    >
    > but that's obviously not 'generic unpluggable kernel RAM'. It's very
    > special RAM: RAM that is free or easily freeable. I never argued that
    > such RAM is not returnable to the hypervisor.
     
     Okay - and 'generic unpluggable kernel RAM' has not been a goal for
     the hypervisor based environments. I believe it is closer to being
     a goal for those machines which want to hot-remove DIMMs or physical
     memory, e.g. those with IA64 machines wishing to remove entire nodes.

    > > > reliable unmapping of "generic kernel RAM" is not possible even in a
    > > > virtualized environment. Think of the 'live pointers' problem i outlined
    > > > in an earlier mail in this thread today.
    > >
    > > Yeah - and that isn't what is being proposed here. The goal is to
    > > ask the kernel to identify some memory which can be legitimately
    > > freed and hasten the freeing of that memory.
    >
    > but that's very easy to identify: check the free list or the clean
    > list(s). No defragmentation necessary. [unless the unit of RAM mapping
    > between hypervisor and guest is too coarse (i.e. not 4K pages).]

     Ah, but the hypervisor often manages large page sizes, e.g. 64 MB.
     It doesn't manage page rights for each guest OS at the 4 K granularity.
     Hypervisors are theoretically light in terms of memory needs and
     general footprint. Picture the overhead of tracking rights/permissions
     of each page of memory and its assignment to any of, say, 256 different
     guest operating systems. For a machine of any size, that would be
     a huge amount of state for a hypervisor to maintain. Would you
     really want a hypervisor to keep that much state? Or is it more
     reasonably for a hypervisor to track, say, 64 MB chunks and the
     rights of that memory for a number of guest operating systems? Even
     if the number of guests is small, the data structures for fast
     memory management would grow quickly.

    gerrit
    -
    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/

  • Next message: Arkadiusz Miskiewicz: "mxser driver in 2.6.14: kernel BUG at drivers/char/mxser.c:1004!"

    Relevant Pages