On Wed, 14 May 2008, Matt Mackall wrote: > > If we would strip the NUMA stuff out and make it an SMP only allocator for > > enterprise apps then the code may become much smaller and simpler. I guess > > Arjan suggested something similar in the past. But that would result in > > SLAB no longer being a general allocator. > > What does this have to do with anything? I'm not talking about going > back to SLAB. I'm talking about plugging the use cases where SLUB > currently loses to SLAB. That's what has to happen before SLAB can be > obsoleted. Both allocators have a different design which leads to different behavior. I do not think the expectation that one must always best the other is reasonable or even possible. I'd be glad if we had some means of increasing the performance in the currently known cases where remote slab free becomes an issue by avoiding the atomic op. AFAICT we so far have been able to compensate for the additional atomic op with a reduced cache footprint and less complexity overall on remote frees and also through improvements in alloc behavior. I hope that the current improvements in 2.6.26 are sufficient to address the concerns with TP-C (which I do not have direct access to and frankly I know very little about the setup etc). We are still not sure exactly why TP-C has a problem. The slab statistics were added to figure that one out. We can get a view of what is going on without having access to the system. I think the current way of compensating for that atomic op is better than getting back to the queue mess. Maybe there is a way of limited use of queues that avoids the atomic op but so far I have not found one. Maybe someone else looking at it will have better ideas. -- 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
