Re: [PATCH] scsi: fix sense_slab/bio swapping livelock

[Peter Zijlstra]

On Wed, 2008-04-09 at 00:11 +0300, Pekka Enberg wrote:
> Christoph Lameter wrote:
> > Hmmmm... Peter has the most experience with these issues. Maybe the best 
> > would be to have this sort of logic in a more general way in the page 
> > allocator? Similar issues surely exist with the page allocator and a fix 
> > there would fix it for all users.
> 
> This needs some support in the slab allocator anyway. Keep in mind that 
> the patch is specifically addressing writeback in OOM conditions so we 
> must (1) prioritize GFP_TEMPORARY allocations over everyone else (which 
> just get NULL) and (2) use the remaining available memory as efficiently 
> as possible for _all_ GFP_TEMPORARY allocations.
> 
> Peter is, however, bringing up a good point that my patch doesn't 
> actually _guarantee_ anything so I'm still wondering if this approach 
> makes any sense... But I sure do like Linus' ideas of marking 
> short-lived allocations and trying harder for them in OOM.

Also, this scheme so far does not provide for a means to detect the end
of pressure situation.

I need both triggers, enter pressure and exit pressure. Enter pressure
is easy enough, that's when normal allocations start failing. Exit
pressure however is more difficult - that is basically when allocations
start succeeding again. You'll see that my patches basically always
attempt a regular allocation as long as we're in the emergency state.

Also, the requirement for usage of emergency memory (GFP_MEMALLOC,
PF_MEMALLOC) is that it will be freed without external conditions. So
while it might be delayed for a while (it might sit in the fragment
assembly cache for a while) it doesn't need any external input to get
freed again:
  - it will either get reclaimed from this cache;
  - it will exit the cache as a full packet and:
    - get dropped, or
    - get processed.



--
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/