[lkml]   [2003]   [Apr]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] first try for swap prefetch
    On April 11, Andrew Morton wrote:
    > Thomas Schlichter <> wrote:
    > > Hi,
    > >
    > > as mentioned a few days ago I was going to try to implement a swap
    > > prefetch to better utilize the free memory. Now here is my first try.
    > That's surprisingly cute. Does it actually do anything noticeable?

    Well, it fills free pagecache memory with swapped pages... ;-)

    But at the moment I can not 'feel' any real improvement... :-(
    I think the problem is that R/O pages are not written to swap space and so not
    prefetched with my patch. But I will look after it...

    > + swapped_entry = kmalloc(sizeof(*swapped_entry), GFP_ATOMIC);
    > These guys will need a slab cache (not SLAB_HW_CACHE_ALIGNED) to save
    > space.

    OK, I'll do it.

    > + swapped_entry = radix_tree_lookup(&swapped_root.tree, entry.val);
    > + if(swapped_entry) {
    > + list_del(&swapped_entry->list);
    > + radix_tree_delete(&swapped_root.tree, entry.val);
    > you can just do
    > if (radix_tree_delete(...) != -ENOENT)
    > list_del(...)
    > + read_swap_cache_async(entry);

    Sorry, but I think I can not. The list_del() needs the value returned by
    radix_tree_lookup(), so I can not kick it... By the way, the only reason for
    the radix tree is to make this list_del() not O(n) for searching the list...
    Do you know how expensive the radix_tree_lookup() is? O(1) or O(log(n))?? For
    my shame I do not really know that data structure... :-(

    > What you want here is a way of telling if the disk(s) which back the swap
    > are idle. We used to have that, but Hugh deleted it. It can be put back,
    > but it's probably better to put a `last_read_request_time' and
    > `last_write_request_time' into struct backing_dev_info. If nobody has used
    > the disk in the past N milliseconds, then start the speculative swapin.

    That's good. I was looking for anything like that but didn't find anything
    fitting in the current sources...

    > It might make sense to poke the speculative swapin code in the page-freeing
    > path too.

    I wanted to do this but don't know which function is the correct one for this.
    But I will search harder... or can you give me a hint?

    > And to put the speculatively-swapped-in pages at the tail of the inactive
    > list (perhaps).

    This may be a good idea...

    > But first-up, some demonstrated goodness is needed...

    Yup, but currently it improves nothing very much, as stated above, I think
    first I should implement the R/O pages thing and investigete which part of
    the kernel works against my code and frees some pages after I just filled

    Thank you for helping me with your comments!

    Best regards
    Thomas[unhandled content-type:application/pgp-signature]
     \ /
      Last update: 2005-03-22 13:34    [W:0.021 / U:17.012 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site