On Wed, 2008-05-14 at 13:33 -0700, Christoph Lameter wrote: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. --
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Andi Kleen | [PATCH x86] [0/16] Various i386/x86-64 changes |
| Vladislav Bolkhovitin | Re: Integration of SCST in the mainstream Linux kernel |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
git: | |
| Gerrit Renker | [PATCH 0/37] dccp: Feature negotiation - last call for comments |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Natalie Protasevich | [BUG] New Kernel Bugs |
| Arjan van de Ven | Re: [GIT]: Networking |
