Re: filecache/swapcache questions [RFC] [RFT] [PATCH] kanoj-mm12-2.3.8 Fix swapoff races

[kanoj@google.engr.sgi.com (Kanoj Sarcar)]

> 
> Hi,
> 
> On Mon, 28 Jun 1999 16:43:59 -0700 (PDT), kanoj@google.engr.sgi.com
> (Kanoj Sarcar) said:
> 
> > This will almost always work, except theoretically, you still can
> > not guarantee forward progress, unless you can stop forks() from
> > happening. That is, given a high enough rate of forking, swapoff
> > is never going to terminate. 
> 
> Then repeat until it converges, ie. until you have no swap entries left.
> No big deal.  Unless the swapoff sweep and the fork are running over pid
> space at exactly the same rate forever (which we do not have to worry
> about!), you will make progress.
>

Stephen,

Seeing that both of us devoted so much time to discussing this,
I felt compelled to look at what is involved in doing what you 
are suggesting. 

To know whether there are any more references left to be eliminated
on a swap page, we can not tolerate a SWAP_MAP_MAX concept; else we
can never determine whether there are processes still referencing the
swap page. Removing SWAP_MAP_MAX is a good thing in itself. The 
swap_map[] array needs to be declared as an array of elements of the 
same size as the page->count field, ie an atomic_t (since there can be
no more references to the swap page than there can be on the physical
page).

Also, I am not sure why you say that fork can not keep ahead of
the swapoff sweep forever. Are you saying it is okay not to guarantee
forward progress of swapoff while a program that keeps on forking 
(and the children exit almost immediately) is running? Then there's
the complexity of clone(CLONE_PID), which creates task structures 
with the same pid, so the pid fencepost algorithm would need to
handle that too ...

Let me know what you think of these two issues, then I can try
to create a patch that does this ... 

Kanoj
kanoj@engr.sgi.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://humbolt.geo.uu.nl/Linux-MM/