Re: [PATCH] 2.2.17pre7 VM enhancement Re: I/O performance on

[Marcelo Tosatti]

On Thu, 29 Jun 2000, Andrea Arcangeli wrote:

> On Thu, 29 Jun 2000, Stephen C. Tweedie wrote:
> 
> >"progress" does not mean freeing a page.  Simply finding a page which
> >can be unmapped from a process's page tables is considered "progress".  
> 
> I agree, the current swap_out design is too much fragile.
> 
> btw, in such area we also have a subtle hack/magic: when we unmap a clean
> page we consider that a "fail" ;), while instead we really did some kind
> of progress. We need to consdier that a fail because we need more margin
> (even if that can lead in unmapping way too much stuff) because such page
> could be shared by more than one pte for example (I remeber I tried to
> consider that a progress and the allocations started failing). Dirty ptes
> in a MAP_SHARED segment instead always return success so they don't have
> such magic hack (even if they could be mapped by more than one pte too)
> and that makes them even more fragile... (of course unmapping an huge
> clean vma and faulting in the cache later is not good but it can be
> handled, while writing to disk at once an huge MAP_SHARED dirty vma would
> probably kill the machine for some time ;)

You said you would have to fix the free_before_allocate issue before
fixing the MAP_SHARED one. 

What is the problem with free_before_allocate now?

Thanks