Tigran, All,
> So, why not go through the entire kernel sources and eliminate all uses of
> kfree_s(), replacing it with kfree() - making the whole thing a little bit
> faster? I see apm and some sound drivers are using kfree_s()..
Eh, no!
kfree_s() is there for two reasons;
o It was there in the previous allocator (before slab allocator).
o It does allow that extra check.
If I had my way, _all_ occurances of kfree() would be replaced with
kfree_s(). There would be a lot of resistance to this as every consumer
would need to know/maintain the size of their allocations. That would
make developers think a bit more about their code (good point), but (in
some cases) would require an extra field in structures to remember the
size (bad point).
I would like to remove the Slab's dependency on the page structure, and
if kfree() disappeared I could do this (kfree_s() would do a search
similar to kmalloc(), but I've a scheme for speeding that up already in
place in my new allocator).
One reason for wanting to remove the page struct dependency is to
support "virtual" (non physically contigious, but virtually contigious)
allocations. I then couldn't use the object's address to find the general
size cache the object belongs to (unless I find the object's physically
address, which could be an expensive operation and probably not too
healthy at interrupt time).
BTW: I know all the objections to using non constant virtual to physical
mappings, please don't go telling them to me again. :)
I've been playing with a new allocation interface, which would extend
the current interface, for use by high frequency allocations;
kmem_cookie_t cookie;
void *objp;
cookie = kmalloc_cookie(1024);
objp = K_COOKIE_TO_MEM(cookie);
...
kfree_cookie(cookie);
where K_COOKIE_TO_MEM() is simply a macro.
Why would this be (much) faster?
The "cookie" is actually part of the new Slab's internal bufctl (buffer
control) which all the existing allocation/release interfaces quickly map
down to. I don't want to feature bloat the allocation API, and I'm sure
there are good reasons to not supporting the above, but I'm simply playing
around with ideas at the moment (when I get the time).
BTW: The kfree_s()'s "extra" test is extremely light (the cs_size is on
the same L1 cache line as the cs_cachep), so losing it won't save you any
noticable CPU cycles.
Mark
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun May 07 2000 - 21:00:12 EST