Hi Glauber, On Wed, Mar 28, 2012 at 9:42 AM, Glauber Costa <glommer@xxxxxxxxxxxxx> wrote: > Hi. > > This is a proposal I've got for how to finally settle down the > question of which slabs should be tracked. The patch I am providing > is for discussion only, and should apply ontop of Suleiman's latest > version posted to the list. > > The idea is to create a new file, memory.kmem.slabs_allowed. > I decided not to overload the slabinfo file for that, but I can, > if you ultimately want to. I just think it is cleaner this way. > As a small rationale, I'd like to somehow show which caches are > available but disabled. And yet, keep the format compatible with > /proc/slabinfo. > > Reading from this file will provide this information > Writers should write a string: > [+-]cache_name > > The wild card * is accepted, but only that. I am leaving > any complex processing to userspace. > > The * wildcard, though, is nice. It allows us to do: > -* (disable all) > +cache1 > +cache2 > > and so on. > > Part of this patch is actually converting the slab pointers in memcg > to a complex memcg-specific structure that can hold a disabled pointer. > > We could actually store it in a free bit in the address, but that is > a first version. Let me know if this is how you would like me to tackle > this. > > With a system like this (either this, or something alike), my opposition > to Suleiman's idea of tracking everything under the sun basically vanishes, > since I can then selectively disable most of them. > > I still prefer a special kmalloc call than a GFP flag, though. How would something like this interact with slab types that will have a per-memcg shrinker? Only do memcg shrinking for a slab type if it's not disabled? While I like the idea of making it configurable by the user, I wonder if we should be adding even more complexity to an already large patchset, at this point. I am also afraid that we might make this too hard setup correctly and use. If it's ok, I'd prefer to keep going with a slab flag being passed to kmem_cache_create, to determine if a slab type should be accounted or not (opt-in), for now. -- Suleiman -- 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