> > I know that most of you do not like aging. Nevertheless, on high stressed
> > systems with less than 128M you will see a critical point whereas the page
> > cache and readahead does not avoid that swapin I/O time needed by a program
> > increases to similar size of the average program time slice.
>
> There's no reason why timeslices should have anything to do with swapin
> IO time; we do not count time spent waiting for IO against the process's
> allocated timeslice.
Yes we do I/O async so while the I/O is in action we could be just back in
userspace, but both shrink_mmap() and swap_out() are not something of
really so light (at least with >128Mbyte of ram). When we are running in
shrink_mmap() the current->counter is decreased as usual.
It's trivial conceptually make shrink_mmap() _fast_, adding two
prev_freeable,next_freeable pointers in the mem_map struct and adding
pages back and forth to the list (at the same time I now update
nr_freeable_pages). Probably I'll do that soon.
I see instead not trivial to decrease the cost of swap_out()...
I agree that the timeslice has nothing to do with swapout/shrink_mmap
issue. But the timeslice _must_ be decremented as now during the
shrink_mmap/swapout passes, because otherwise we would risk to stall the
not trashing process 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/