nr_async_pages and swapin readahead on -ac series

nr_async_pages and swapin readahead on -ac series

[Marcelo Tosatti]

Rik, 
 
On the latest 2.4 -ac series, nr_async_pages is only being used to count
swap outs, and not for both swap reads and writes (as Linus tree does).

The problem is that nr_async_pages is used to limit swapin readahead based
on the number of on flight swap pages (mm/memory.c::swapin_readahead):

                /* Don't block on I/O for read-ahead */
                if (atomic_read(&nr_async_pages) >= pager_daemon.swap_cluster
                                * (1 << page_cluster)) {
                        while (i++ < num)
                                swap_free(SWP_ENTRY(SWP_TYPE(entry), offset++));
                        break;
                }


So swapin readahead is (theorically) unlimited. 

One possible way to limit the swapin readahead is to split nr_async_pages
into read and write counters and change all places which use
nr_async_pages accordingly.

However, I think a better solution is to ask the block layer if there are
free requests on the device queue and stop the readahead in case there are
no free ones. (we don't something like that right now, but it can be
easily done in the block layer)

Comments? 


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: nr_async_pages and swapin readahead on -ac series

[Rik van Riel]

On Wed, 7 Mar 2001, Marcelo Tosatti wrote:

> On the latest 2.4 -ac series, nr_async_pages is only being used to count
> swap outs, and not for both swap reads and writes (as Linus tree does).
>
> The problem is that nr_async_pages is used to limit swapin readahead based
> on the number of on flight swap pages (mm/memory.c::swapin_readahead):
>
>                 /* Don't block on I/O for read-ahead */
>                 if (atomic_read(&nr_async_pages) >= pager_daemon.swap_cluster
>                                 * (1 << page_cluster)) {
>                         while (i++ < num)
>                                 swap_free(SWP_ENTRY(SWP_TYPE(entry), offset++));
>                         break;
>                 }
>
>
> So swapin readahead is (theorically) unlimited.

> However, I think a better solution is to ask the block layer if
> there are free requests on the device queue and stop the
> readahead in case there are no free ones. (we don't something
> like that right now, but it can be easily done in the block
> layer)

An even better idea would be to only do swapin readahead if
there is memory available ...

regards,

Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com/

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: nr_async_pages and swapin readahead on -ac series

[Stephen C. Tweedie]

Hi,

On Wed, Mar 07, 2001 at 10:57:21PM -0300, Marcelo Tosatti wrote:
>  
> On the latest 2.4 -ac series, nr_async_pages is only being used to count
> swap outs, and not for both swap reads and writes (as Linus tree does).

Seems fine to me.

> The problem is that nr_async_pages is used to limit swapin readahead based
> on the number of on flight swap pages (mm/memory.c::swapin_readahead):

That's probably a mistake: we don't throttle readahead on normal files
in this manner.

Swapin is always synchronous: it happens in response to a task's page
fault.  As such it is always going to be rate-limited automatically.
I don't think it's too important to count reads in nr_async_pages, nor
to throttle readaheads if nr_async_pages is too large.

Cheers,
 Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: nr_async_pages and swapin readahead on -ac series

[Marcelo Tosatti]

On Thu, 8 Mar 2001, Stephen C. Tweedie wrote:

> Hi,
> 
> On Wed, Mar 07, 2001 at 10:57:21PM -0300, Marcelo Tosatti wrote:
> >  
> > On the latest 2.4 -ac series, nr_async_pages is only being used to count
> > swap outs, and not for both swap reads and writes (as Linus tree does).
> 
> Seems fine to me.
> 
> > The problem is that nr_async_pages is used to limit swapin readahead based
> > on the number of on flight swap pages (mm/memory.c::swapin_readahead):
> 
> That's probably a mistake: we don't throttle readahead on normal files
> in this manner.
> 
> Swapin is always synchronous: it happens in response to a task's page
> fault.  As such it is always going to be rate-limited automatically.
> I don't think it's too important to count reads in nr_async_pages, nor
> to throttle readaheads if nr_async_pages is too large.

Its not really throttling. We just _bypass_ the readahead's in case we got
too much. 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: nr_async_pages and swapin readahead on -ac series

[Stephen C. Tweedie]

Hi,

On Thu, Mar 08, 2001 at 07:47:59PM -0300, Marcelo Tosatti wrote:
> 
> > Swapin is always synchronous: it happens in response to a task's page
> > fault.  As such it is always going to be rate-limited automatically.
> > I don't think it's too important to count reads in nr_async_pages, nor
> > to throttle readaheads if nr_async_pages is too large.
> 
> Its not really throttling. We just _bypass_ the readahead's in case we got
> too much. 

I know, but I still think it's worth doing the readahead in any case.
We've got 8192 request slots per swap device so we're not going to
suddenly go synchronous because of readahead, and the callers are
naturally throttled (because they wait synchronously on the requested
page) so we don't have to worry about submitting unbounded IO.

An extra seek is _so_ much more expensive than the
readahead/readaround that I doubt it's worth making it conditional.

Cheers,
 Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/