Re: [PATCH 1/3] page-allocator: Under memory pressure, wait onpressure to relieve instead of congestion

[Mel Gorman]

On Tue, Mar 09, 2010 at 10:09:11AM -0600, Christoph Lameter wrote:
> On Tue, 9 Mar 2010, Christian Ehrhardt wrote:
> 
> > > What happens if memory becomes available in another zone? Lets say we are
> > > waiting on HIGHMEM and memory in ZONE_NORMAL becomes available?
> >
> > Do you mean the same as Nick asked or another aspect of it?
> > citation:
> > "I mean the other way around. If that zone's watermarks are not met, then why
> > shouldn't it be woken up by other zones reaching their watermarks."
> 
> Just saw that exchange. Yes it is similar. Mel only thought about NUMA
> but the situation can also occur in !NUMA because multiple zones do not
> require NUMA.
> 

True, although rare. Elsewhere I suggested that the wait could be on a
per-node basis instead of per-zone. My main concern there would be
adding a new hot cache line in the page free path or an unfortunate mix
of zone and node logic. I'm not fully convinced it's worth it but will
check it out.

> If a process goes to sleep on an allocation that has a preferred zone of
> HIGHMEM then other processors may free up memory in ZONE_DMA and
> ZONE_NORMAL and therefore memory may become available but the process will
> continue to sleep.
> 

Until it's timeout at least. It's still better than the current
situation of sleeping on congestion.

The ideal would be waiting on a per-node basis. I'm just not liking having
to look up the node structure when freeing a patch of pages and making a
cache line in there unnecessarily hot.

> The wait structure needs to be placed in the pgdat structure to make it
> node specific.
> 
> But then an overallocated node may stall processes. If that node is full
> of unreclaimable memory then the process may never wake up?
> 

Processes wake after a timeout.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab
--
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/