[lkml]   [2005]   [Feb]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC 2.6.11-rc2-mm2 0/7] mm: manual page migration -- overview II
    Andi wrote:
    > I still think it's fundamentally unclean and racy. External processes
    > shouldn't mess with virtual addresses of other processes.

    It's not really messing with (changing) the virtual addresses of
    another process. It's messing with the physical placement. It's
    using the virtual addresses to help choose which pages to move.

    Do you have any better way to suggest, Andi, for a batch manager to
    relocate a job? The typical scenario, as Ray explained it to me, is
    thus. A lower priority job, after running a while, is displaced by a
    higher priority job that needs a large number of nodes. Later on enough
    nodes to run the lower priority job become available elsewhere. The
    lower priority job can either continue to wait for its original nodes to
    come free (after the high priority job finishes) or it can be relocated
    to the nodes available now.

    How would you recommend that the batch manager move that job to the
    nodes that can run it? The layout of allocated memory pages and tasks
    for that job must be preserved in order to keep the same performance.
    The migration method needs to scale to hundreds, or more, of nodes.

    (I'm starting to have visions of vma's having externally visible id's,
    in a per-task namespace.)

    I won't rest till it's the best ...
    Programmer, Linux Scalability
    Paul Jackson <> 1.650.933.1373, 1.925.600.0401
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:10    [W:0.020 / U:63.216 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site