On Wed, 2008-05-14 at 13:33 -0700, Christoph Lameter wrote: > On Wed, 14 May 2008, Matt Mackall wrote: > > > > allocator? > > > > No, slow path here means we're already under memory pressure, so we > > don't care if something takes longer if it saves memory. > > So expire the queues under memory pressure only? Trigger queue cleanup > from reclaim? This wouldn't be my first thought. The batch size could be potentially huge and we'd have to worry about latency issues. But here are some other thoughts: First, we should obviously always expire all queues when we hit low water marks as it'll be cheaper/faster than other forms of reclaim. Second, if our queues were per-slab (this might be hard, I realize), we can sweep the queue at alloc time. We can also sweep before falling back to the page allocator. That should guarantee that delayed frees don't negatively impact fragmentation. And lastly, we can always have a periodic thread/timer/workqueue operation. So far this is a bunch of hand-waving but I think this ends up basically being an anti-magazine. A magazine puts a per-cpu queue on the alloc side which costs on both the alloc and free side, regardless of whether the workload demands it. This puts a per-cpu queue on the free side that we can bypass in the cache-friendly case. I think that's a step in the right direction. -- Mathematics is the supreme nostalgia of our time. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
