I noticed the bug one hour ago and I fixed it now.
> + if (PageSwapCache(page)) {
> + unsigned long entry = page->offset;
> + if (PageTestandClearDirty(page) &&
^^^^^^^^^^^^^^^^^^^^^^^^^^^
> + swap_count(entry) > 1)
> + {
> + if (!(gfp_mask & __GFP_IO))
> + continue;
^^^^^^^^^
> + entry = page->offset;
> + set_bit(PG_locked, &page->flags);
> + atomic_inc(&page->count);
> + rw_swap_page(WRITE, entry, page, 0);
> + atomic_dec(&page->count);
> + }
> + delete_from_swap_cache(page);
> + return 1;
> + }
> +
With the bug fixed it seems really rock solid. It would be interesting
making performance comparison with kernels that are swapping out in
swap_out() (e.g. clean pre7). I am not sure it's a win (but I'm sure it's
more fun ;). The swapout performances are a bit decreased even if
sometimes (in the second pass) my benchmark give me super results with
this my new code (43 sec, that's been the record of every other kernel
tried).
The only thing I don't like is that the kernel seems to stall a bit every
some seconds in the grow_freeabe() path (the old swap_out()), also the
profiling report try_to_swap_out() as the function where the kernel is
passing most of the time (20 timer interrupt against 10 of shrink_mmap).
Maybe because now I'm recalling grow_freeable() many more times than I was
used to do... Maybe I should reinsert something like the smart swapout
weight code to allow grow_freeable() to scale greatly... It's just quite
good though.
The fixed patch (arca-vm-22) can be downloaded from here:
ftp://e-mind.com/pub/linux/kernel-patches/2.2.0-pre7-arca-VM-22.gz
(if it's too slow drop me a line and I'll post privately it via email, I
am not posting it here again to not spam too much ;)
Andrea Arcangeli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/