Nick Piggin a écrit :
Eric Dumazet wrote:
__vmalloc_area_node() is a litle bit pessimist when allocating space
for storing struct page pointers.
When allocating more than 4 MB on ia32, or 2 MB on x86_64,
__vmalloc_area_node() has to allocate more than PAGE_SIZE bytes to
store pointers to page structs. This means that two TLB translations
are needed to access data.
This patch tries a kmalloc() call, then only if this first attempt
failed, a vmalloc() is performed. (Later, at vfree() time we chose
kfree() or vfree() with a test on flags & VM_VPAGES : no change is
needed)
Most of the time, the first kmalloc() should be OK, so we reduce TLB
usage.
But this is only TLB usage when managing (read: freeing) the vmalloc pages,
isn't it? Not when actually accessing the data.
Yes indeed...
I was trying to reduce time taken by a processes handling lot of files (thus
vmalloc()ing fdtables and fdset). I noticed a high oprofile hit in
fget_light(). I suspected overhead caused by vmalloc(), but obviously, once
the vmalloc() mapping is done, the array of pointers wont be used until vfree().
I'd be inclined to NACK this, unless you can show an improvement somewhere:
it is suboptimal to even _try_ allocating higher order pages.
Your point is valid. And it seems there is not much cpu used to linearly scan
vmlist (to find the vm_struct), at least on my little servers.
Eric
-
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]
