On 10/07/2011 12:27 PM, Glauber Costa wrote: > Hi Pavel, > > On 10/06/2011 08:23 PM, Pavel Emelyanov wrote: >> The idea of how to generate and ID for an arbitrary slab object is simple: >> >> - The ID is 128 bits >> - The upper 64 bits are slab ID >> - The lower 64 bits are object index withing a slab (yes, it's too many, >> but is done for simplicity - not to deal with 96-bit numbers) >> - The slab ID is the 48-bit per-cpu monotonic counter mixed with 16-bit >> cpuid. Even if being incremented 1M times per second the first part >> will stay uniqe for 200+ years. The cpuid is required to make values >> picked on two cpus differ. > > So why can't we just use tighter numbers, and leave some reserved fields > instead ? Well, we have to save the ID on the slab and for 64-bit kernel we can already use the 64-bit mapping field. For 32-bit kernels 32-bit value is not enough as it can overlap in several days (like 32bit jiffies do) which is not enough. > Having ids in the objects of the slab may prove useful in the future for > other uses as well. > > For instance, concurrent to that, we're trying to figure out ways to > have per-cgroup pages/objects accounted in the memory controller. > > The most up2date proposals create an entire kmem cache for each cgroup, > thus trivially guaranteeing uniqueness. It however, leads to fragmentation. > Having the objects to be IDed and being cgroup part of this id, could > help us achieve the same goal with less fragmentation. That's good point! I can extend the patches to provide the space reservation infrastructure for slabs. Thanks, Pavel -- 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>