On Wed, 8 Feb 2012, Mel Gorman wrote: > On Wed, Feb 08, 2012 at 01:49:05PM -0600, Christoph Lameter wrote: > > On Wed, 8 Feb 2012, Mel Gorman wrote: > > > > > Ok, I looked into what is necessary to replace these with checking a page > > > flag and the cost shifts quite a bit and ends up being more expensive. > > > > That is only true if you go the slab route. > > Well, yes but both slab and slub have to be supported. I see no reason > why I would choose to make this a slab-only or slub-only feature. Slob is > not supported because it's not expected that a platform using slob is also > going to use network-based swap. I think so far the patches in particular to slab.c are pretty significant in impact. > > Slab suffers from not having > > the page struct pointer readily available. The changes are likely already > > impacting slab performance without the virt_to_page patch. > > > > The performance impact only comes into play when swap is on a network > device and pfmemalloc reserves are in use. The rest of the time the check > on ac avoids all the cost and there is a micro-optimisation later to avoid > calling a function (patch 12). We have been down this road too many times. Logic is added to critical paths and memory structures grow. This is not free. And for NBD swap support? Pretty exotic use case. > Ok, are you asking that I use the page flag for slub and leave kmem_cache_cpu > alone in the slub case? I can certainly check it out if that's what you > are asking for. No I am not asking for something. Still thinking about the best way to address the issues. I think we can easily come up with a minimally invasive patch for slub. Not sure about slab at this point. I think we could avoid most of the new fields but this requires some tinkering. I have a day @ home tomorrow which hopefully gives me a chance to put some focus on this issue. > I did come up with a way: the necessary information is in ac and slabp > on slab :/ . There are not exactly many ways that the information can > be recorded. Wish we had something that would not involve increasing the number of fields in these slab structures. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>