Messages in this thread |  | | Date | Thu, 21 Jan 1999 20:53:28 +0100 (CET) | | From | Andrea Arcangeli <> | | Subject | Re: MM deadlock [was: Re: arca-vm-8...] |
| |
On Thu, 21 Jan 1999, Stephen C. Tweedie wrote:
> > 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/
|  |