Re: [PATCH] vm - swap_prefetch-11

[Con Kolivas <kernel@kolivas.org>]

On Wed, 28 Sep 2005 04:56 am, Jonathan Corbet wrote:
> Hi, Con,
>
> > This patch implements swap prefetching when the vm is relatively idle and
> > there is free ram available.
>
> I'm having a look at it now (better late than never...), and a couple of
> questions come to mind...

Hey thanks for looking. It can be quite hard for people to find time to review 
patches and I appreciate the effort.

> The more general of the two is: would it make sense to somehow merge
> your swapped_entry data structure with Rik's page-remembering scheme for
> CLOCK-PRO?  Assumed that both are someday destined for inclusion, it
> seems it would make sense to add just one "remember info about swapped
> pages" data structure, rather than two.

Indeed it would. I was hoping the time frame for inclusion of swap prefetching 
would be much shorter than clock pro given the relatively intrusive nature of 
clock pro. It would make sense to update the accounting to that of clock pro 
if/when clock pro was pushed. One of the features of the current accounting 
is it is extremely cheap and slightly sloppy on purpose since there is no 
point to being perfectly accurate and incur the extra overhead. Once that 
overhead is considered worthwhile for clock pro algorithms we can just use 
that data.

> Second question:
> It looks like you are adding these fields to every address_space
> structure in the system - and there can be a fair number of those.  But
>
> further down, when it comes time to remember a swapped page:

> You're only actually remembering pages associated with a single address
> space.
>
> Do you anticipate adding prefetching from other address spaces as well?
> If not, it might be worth putting these structures somewhere else to
> avoid bloating the address_space structure.
>
> ...or am I missing something again...?

Nope you're definitely not missing something. As you're well aware code ends 
up often being far from the original attempt. It's the legacy of the code 
evolution and it was something I would hopefully have thought about myself 
without being prompted by someone else. I'll have to get onto that with the 
next version.

Just as a data point there is still a workload that is inappopriately causing 
out-of-memory conditions when it shouldn't and only once I nail all known 
issues from the -ck users will I push it to -mm.

Thanks again

Cheers,
Con
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/