[lkml]   [2006]   [Sep]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subject[RFC][PATCH 0/2] Swap token re-tuned

    Here's a brief up on the next two mails.

    PATCH 1:

    In the current implementation of swap token tuning, grab swap token is
    made from :
    1) after page_cache_read (filemap.c) and
    2) after the readahead logic in do_swap_page (memory.c)

    IMO, the contention for the swap token should happen _before_ the
    aforementioned calls, because in the event of low system memory, calls
    to freeup space will be made later from page_cache_read and
    read_swap_cache_async , so we want to avoid "false LRU" pages by
    grabbing the token before the VM starts searching for replacement

    PATCH 2:

    Instead of using TIMEOUT as a parameter to transfer the token, I think a
    better solution is to hand it over to a process that proves its

    What my scheme does, is to find out how frequently a process is calling
    these functions. The processes that call these more frequently get a
    higher priority.
    The idea is to guarantee that a high priority process gets the token.
    The priority of a process is determined by the number of consecutive
    calls to swap-in and no-page. I mean "consecutive" not from the
    scheduler point of view, but from the process point of view. In other
    words, if the task called these functions every time it was scheduled,
    it means it is not getting any further with its execution.

    This way, its a matter of simple comparison of task priorities, to
    decide whether to transfer the token or not.

    I did some testing with the two patches combined and the results are as

    Current Upstream implementation:

    root@ashbert:~/crap# time ./qsbench -n 9000000 -p 3 -s 1420300
    seed = 1420300
    seed = 1420300
    seed = 1420300

    real 3m40.124s
    user 0m12.060s
    sys 0m0.940s


    With my implementation :

    root@ashbert:~/crap# time ./qsbench -n 9000000 -p 3 -s 1420300
    seed = 1420300
    seed = 1420300
    seed = 1420300

    real 2m58.708s
    user 0m11.880s
    sys 0m1.070s

    My test machine:

    1.69Ghz CPU
    64M RAM
    7200rpm hdd
    2MB L2 cache
    vanilla kernel 2.6.18
    Ubuntu dapper with gnome.

    Any comments, suggestions, ideas ?


    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: 2006-09-29 20:45    [W:0.021 / U:7.040 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site