[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] swapin readahead
On 1 Dec 1998, Zlatko Calusic wrote:
> Rik van Riel <H.H.vanRiel@phys.uu.nl> writes:
>
> > In my experience allocations aren't the big problem but
> > deallocations. I guess we lose some memory there :(
>
> Yes. something like that. Since nobody asked pages to swap in (we
> decided to swap them in) it looks like nobody frees them. :)
> So we should free them somewhere, probably.
I took the bet that shrink_mmap() would take care of that, but
aperrantly not always :(
> > > Also, looking at the patch source, it looks like the comment there is
> > > completely misleading, as the for() loop is not doing anything, at
> + read_swap_cache_async(SWP_ENTRY(SWP_TYPE(entry), offset),
> +0);
> + break;
> + } ^^^^^^
>
> Last break in the for() loop, exits the loop after the very first
> pass. Why don't you get get rid of the loop, then:
Whoops, this break was left there from a previous editing
round and is removed now. I completely oversaw that one,
I guess that means I should go over the code with a comb
now... :)
> I wish you luck with the swapin readahed. I'm also very interested
> in the impact it could made, since my tests revealed that swapping
> in adjacent pages from swap is quite common operation, so in some
> workloads it could be a big win (hogmem, for instance, would
> probably be much faster :)).
For the pure readahead cache system we'd only need a 10%
hit rate to increase performance twofold (Rogier Wolff and
I calculated this once on the transfer/seek ratio of disks).
Of course a 10% hit ratio means we swap out 90% of stuff
that'd otherwise stay in memory, so it's not a clear picture
at all.
We probably want to increase the readahead when we satisfy
more than 20% of all page faults (that involve a swap area)
from the cache and decrease it when we go below 10%.
Then, of course, we'd also need to weigh average over a minute
or 300 swapins, whichever takes longer. And we need to take
memory and I/O pressure into account so we don't fill up memory
and I/O bandwidth with useless work...
cheers,
Rik -- now completely used to dvorak kbd layout...
+-------------------------------------------------------------------+
| Linux memory management tour guide. H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+
--
This is a majordomo managed list. To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org