Re: [2.4] heavy-load under swap space shortage

[Marcelo Tosatti]

On Tue, 16 Mar 2004, Nick Piggin wrote:

> 
> 
> Andrea Arcangeli wrote:
> 
> >On Tue, Mar 16, 2004 at 01:37:04AM +1100, Nick Piggin wrote:
> >
> >>This case I think is well worth the unfairness it causes, because it
> >>means your zone's pages can be freed quickly and without freeing pages
> >>from other zones.
> >>
> >
> >freeing pages from other zones is perfectly fine, the classzone design
> >gets it right, you have to free memory from the other zones too or you
> >have no way to work on a 1G machine. you call the thing "unfair" when it
> >has nothing to do with fariness, your unfariness is the slowdown I
> >pointed out, it's all about being able to maintain a more reliable cache
> >information from the point of view of the pagecache users (the pagecache
> >users cares at the _classzone_, they can't care about the zones
> >themself), it has nothing to do with fairness.
> >
> >
> 
> What I meant by unfairness is that low zone scanning in response
> to low zone pressure will not put any pressure on higher zones.
> Thus pages in higher zones have an advantage.
> 
> We do scan lowmem in response to highmem pressure.

Hi Nick, 

I'm having a good time reading this discussion, so let me jump in.

Sure, the "unfairness" between lowmem and highmem exists. Quoting what 
you said, "pages in higher zones have an advantage". 

That is natural, after all the necessity for lowmem pages is much higher
than the need for highmem pages. And this necessity for the lowmem
precious increases as far as the lowmem/highmem ratio grows.

As Andrew has demonstrated, the problems previously caused by such
"unfairness" are non existant with per-zone LRU lists.

So, yes, we have unfairness between lowmem and highmem, and yes, that is
the way it should be.

I felt you had a problem with such a thing, however I dont see one.

Am I missing something?

Regards

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