lkml.org 
[lkml]   [1999]   [Jan]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:49    [from the cache]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and my Meterkast|Read the blog