lkml.org 
[lkml]   [2005]   [Nov]   [6]   [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 Nov 4, 2005, at 10:31:48, Linus Torvalds wrote:
    > I can pretty much guarantee that any kernel I maintain will never
    > have dynamic kernel pointers: when some memory has been allocated
    > with kmalloc() (or equivalent routines - pretty much _any_ kernel
    > allocation), it stays put.

    Hmm, this brings up something that I haven't seen discussed on this
    list (maybe a long time ago, but perhaps it should be brought up
    again?). What are the pros/cons to having a non-physically-linear
    kernel virtual memory space? Would it be theoretically possible to
    allow some kind of dynamic kernel page swapping, such that the _same_
    kernel-virtual pointer goes to a different physical memory page?
    That would definitely satisfy the memory hotplug people, but I don't
    know what the tradeoffs would be for normal boxen.

    It seems like the trick would be to make sure that page accesses
    _during_ the swap are correctly handled. If the page-swapper
    included code in the kernel fault handler to notice that a page was
    in the process of being swapped out/in by another CPU, it could just
    wait for swap-in to finish and then resume from the new page. This
    would get messy with DMA and non-cpu memory accessors and such, which
    are what I assume the reasons for not implementing this in the past
    have been.

    From what I can see, the really dumb-obvious-slow method would be to
    call the first and last parts of software-suspend. As memory hotplug
    is a relatively rare event, this would probably work well enough
    given the requirements:
    1) Run software suspend pre-memory-dump code
    2) Move pages off the to-be-removed node, remapping the kernel
    space to the new locations.
    3) Mark the node so that new pages don't end up on it
    4) Run software suspend post-memory-reload code

    <random-guessing>
    Perhaps the non-contiguous memory support would be of some help here?
    </random-guessing>

    Cheers,
    Kyle Moffett

    --
    Simple things should be simple and complex things should be possible
    -- Alan Kay



    -
    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 09:47    [W:0.023 / U:61.868 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site