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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |