lkml.org 
[lkml]   [2006]   [Aug]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [MODSLAB 3/7] A Kmalloc subsystem
On Thu, 17 Aug 2006, Manfred Spraul wrote:

> I'm not sure that the current approach with virt_to_page()/vmalloc_to_page()
> is the right thing(tm): Both functions are slow.

Right. Would be great to avoid it but if we have to use it then I think we
should just store as much metainformation in the page as possible.

> If you have non-power-of-two caches, you could store the control data at
> (addr&(~PAGE_SIZE)) - the lookup would be much faster. I wrote a patch a few
> weeks ago, it's attached.

That would only work for slabs that use order 0 pages.

> Right now we have a few slab users that perform kmalloc(PAGE_SIZE). But that's
> a mostly for historic reasons: kmalloc was significantly (IIRC up to factor
> 10) faster than get_free_pages(). Now get_free_pages() also contains per-cpu
> structures, so we could convert __get_name or the pipe code back to
> get_free_pages().

Note that the caches of the page allocator only work for zero order pages.

And the reason for the existence of those caches is questionable.
We have repeatedly found in pratical tests that switching off these
caches has no influence on performance whatsoever.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-08-17 18:29    [W:0.096 / U:0.688 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site