Messages in this thread | | | From | Thomas Schlichter <> | Subject | Re: [RFC] first try for swap prefetch | Date | Fri, 11 Apr 2003 13:51:55 +0200 |
| |
On April 11, Andrew Morton wrote: > Thomas Schlichter <schlicht@uni-mannheim.de> 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 them...
Thank you for helping me with your comments!
Best regards Thomas[unhandled content-type:application/pgp-signature] | |