On Wed, Jan 02, 2008 at 02:42:20PM -0800, John Reiser wrote: > It looks more complicated to me. > > When include/linux/slab.h is in view, then I trace > (where indentation indicates logical call [inline, or physical call]): > kmalloc include/linux/slab.h > __kmalloc mm/slab.c > __do_kmalloc mm/slab.c > __cache_alloc mm/slab.c > __do_cache_alloc mm/slab.c > ____cache_alloc mm/slab.c > cpu_cache_get mm/slab.c
You're paying way too much attention to the implementation. The rules are simple: 1 - kmalloc and kfree and just like malloc and free - an object's contents are destroyed between kfree and kmalloc 2 - kmem_cache_alloc and kmem_cache_free are just like malloc and free, except that an object may come out of kmem_cache_alloc partially initialized There is another requirement on kmem_cache_free - that an object be passed in in the same initialization state as the constructor would create. You can interpret this as state being preserved between kmem_cache_free and kmem_cache_alloc, which is how it is actually implemented, or as the constructor always being called before kmem_cache_alloc returns. The second makes it look more like malloc and free. > When include/linux/slab_def.h is in view, then I trace: > For a size that is constant at compile time [very often the case], > then I trace: > > kmalloc include/linux/slab_def.h > kmem_cache_alloc mm/slab.c > __cache_alloc mm/slab.c > <<and continues as in first case above>> Yes, kmalloc implements its size buckets as kmem_cache_alloc slabs. So what? If you look at /proc/slabinfo, the size-n slabs you see belong to kmalloc. But that's an implementation detail that has nothing to do with the contract you make when calling kmalloc. > The slab allocator is by far the most used case. slub and slob > have not yet been used during my explorations, as far as I can tell. Right now, it's configurable, and the default configuration uses slab. > Under DEBUG, then cache_init_objs() in mm/slab.c does not call the ctor > if SLAB_POISON. Under no-DEBUG, then cache_init_objs() always calls > the ctor. So here is an exception to the proposed rule, and quite > different *semantics* for DEBUG versus no-DEBUG. Also, cache_init_objs > is not the allocator, but only the initial condition. No, there is no semantic difference here, only a difference in when the objects are constructed depending on slab poisoning. When poisoning is in effect, the objects are constructed as late as possible. When it's not, they are contructed earlier. > Under DEBUG, then cache_alloc_debugcheck_after() in mm/slab.c calls > the ctor if SLAB_POISON. Under no-DEBUG, then cache_alloc_debugcheck_after() > is a no-op. Again, a difference in *semantics* between DEBUG and > no-DEBUG. No, these two supposed semantics differences combine to make no semantic difference. > Altogether: the slab ctor is called once per object; except if DEBUG and > SLAB_POISON, when kfree() is considered to destroy the old object and > kmalloc is considered to create a new object (yet the two objects occupy > identical address space.) In the case of no-DEBUG slab, then the ctor > is never called as a result of calling kmalloc. The kmalloc slabs have no constructor, so of course no constructor is called as a result of calling kmalloc. > So kmalloc+kfree is distinctly different in semantics from malloc+free, > at least as implemented by slab, the most common case. No, they are identical. > Now, in my patches, I CHANGED the semantics of slab __cache_alloc __cache_alloc is an implementation detail - you don't describe it to valgrind any more that you would describe some internal malloc function. You need to describe kmalloc/kfree and kmem_cache_alloc/kmem_cache_free, which are both fairly close (kmalloc/kfree being identical) to malloc/free. > so that it calls the ctor always, ignoring both no-DEBUG and SLAB_POISON. > If there is a ctor, then this makes kmalloc+kfree closer to malloc+free. > But if there is no ctor, then things are murky again. Should the result > of kmalloc() be marked as if it were returned from malloc() or not? > [I.e., are the contents undefined or defined?] Undefined. > In particular, I'm confused by allocations > which return a "page": either "struct page *", or a "char *" with > an aligned group of char of size PAGE_SIZE in the virtual address space. > Help? Examples? I don't know what exactly you're referring to, nor what the problem is. Jeff -- Work email - jdike at linux dot intel dot com ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel