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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
