• Ingo Molnar's avatar
    [PATCH] remove sys_set_zone_reclaim() · 6cb54819
    Ingo Molnar authored
    This removes sys_set_zone_reclaim() for now.  While i'm sure Martin is
    trying to solve a real problem, we must not hard-code an incomplete and
    insufficient approach into a syscall, because syscalls are pretty much
    for eternity.  I am quite strongly convinced that this syscall must not
    hit v2.6.13 in its current form.
    
    Firstly, the syscall lacks basic syscall design: e.g. it allows the
    global setting of VM policy for unprivileged users. (!) [ Imagine an
    Oracle installation and a SAP installation on the same NUMA box fighting
    over the 'optimal' setting for this flag. What will they do? Will they
    try to set the flag to their own preferred value every second or so? ]
    
    Secondly, it was added based on a single datapoint from Martin:
    
     http://marc.theaimsgroup.com/?l=linux-mm&m=111763597218177&w=2
    
    where Martin characterizes the numbers the following way:
    
     ' Run-to-run variability for "make -j" is huge, so these numbers aren't
       terribly useful except to see that with reclaim the benchmark still
       finishes in a reasonable amount of time. '
    
    in other words: the fundamental problem has likely not been solved, only
    a tendential move into the right direction has been observed, and a
    handful of numbers were picked out of a set of hugely variable results,
    without showing the variability data. How much variance is there
    run-to-run?
    
    I'd really suggest to first walk the walk and see what's needed to get
    stable & predictable kernel compilation numbers on that NUMA box, before
    adding random syscalls to tune a particular aspect of the VM ... which
    approach might not even matter once the whole picture has been analyzed
    and understood!
    
    The third, most important point is that the syscall exposes VM tuning
    internals in a completely unstructured way. What sense does it make to
    have a _GLOBAL_ per-node setting for 'should we go to another node for
    reclaim'? If then it might make sense to do this per-app, via numalib or
    so.
    
    The change is minimalistic in that it doesnt remove the syscall and the
    underlying infrastructure changes, only the user-visible changes.  We
    could perhaps add a CAP_SYS_ADMIN-only sysctl for this hack, a'ka
    /proc/sys/vm/swappiness, but even that looks quite counterproductive
    when the generic approach is that we are trying to reduce the number of
    external factors in the VM balance picture.
    Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
    Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    6cb54819
entry.S 42.9 KB