Cc: Hugh Dickins <hugh@...>, Peter Zijlstra <a.p.zijlstra@...>, Christoph Lameter <clameter@...>, James Bottomley <James.Bottomley@...>, Andrew Morton <akpm@...>, FUJITA Tomonori <fujita.tomonori@...>, Jens Axboe <jens.axboe@...>, Rafael J. Wysocki <rjw@...>, <linux-kernel@...>
Actually, I don't think this is SLAB-specific, since there are potentially
the same issues for pages.
I suspect the right thing to do is not to mark them for "IO", but mark
them for "short-lived", and allow short-lived allocations that don't have
extended lifetimes to succeed even when a "real" allocation wouldn't.
When we are under memory pressure, a normal allocation generally needs to
clear up enough memory from elsewhere to succeed. But a short-lived
allocation without any long-term lifetimes would be known to release its
memory back to the pool, so it can be allowed to go ahead when a normal
memory allocation would not.
Examples of short-lived allocations:
- IO requests
- temporary network packets that don't get queued up (eg "ACK" packet) as
opposed to those that do get queued (incoming _or_ outgoing queues)
- things like the temporary buffers for "getname()/putname()" etc.
That said, even a lot of temporary allocations can at times have issues.
If your IO layer is dead, your IO request queues that _should_ have been
very temporary may end up staying around for a long time. But I do think
that it makes sense to prioritize allocations that are known to be short-
lived.
(It might also allows us to allocate them from different pools and just
generally have other heuristics for cache behaviour - short-lived
allocations simply have different behaviour)
Linus
--
