Bug 581459 - vmalloc is slow
vmalloc is slow
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
14
All Linux
low Severity medium
: ---
: ---
Assigned To: Rik van Riel
Fedora Extras Quality Assurance
:
Depends On: 582522
Blocks: 583026 619331
  Show dependency treegraph
 
Reported: 2010-04-12 06:28 EDT by Steve Whitehouse
Modified: 2010-11-18 10:41 EST (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 583026 (view as bug list)
Environment:
Last Closed: 2010-11-18 10:41:15 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Test module used to measure vmalloc speed (804 bytes, text/x-csrc)
2010-04-12 06:31 EDT, Steve Whitehouse
no flags Details
Test patch to help track down vmalloc issue (429 bytes, patch)
2010-04-12 06:33 EDT, Steve Whitehouse
no flags Details | Diff

  None (edit)
Description Steve Whitehouse 2010-04-12 06:28:50 EDT
Measurements of the speed of vmalloc show that it appears to be slower than it ought to be by about 10x based on a set of measurements on recent kernels. See below for details of the test and results.
Comment 1 Steve Whitehouse 2010-04-12 06:31:37 EDT
Created attachment 405928 [details]
Test module used to measure vmalloc speed

This test module does one million loops of vmalloc two pages, touch memory, vfree and then prints out the time taken. The results from a recent upstream kernel (2.6.34-rc2) look like this:

vmalloc took 148798983 us
vmalloc took 151664529 us
vmalloc took 152416398 us
vmalloc took 151837733 us
Comment 2 Steve Whitehouse 2010-04-12 06:33:14 EDT
Created attachment 405929 [details]
Test patch to help track down vmalloc issue

With the attached patch applied, the new results from the test module look like this:

vmalloc took 15363634 us
vmalloc took 15358026 us
vmalloc took 15240955 us
vmalloc took 15402302 us


thats a 10x speed up...
Comment 4 Steve Whitehouse 2010-04-12 06:37:59 EDT
It looks like the issue is that the lazy TLB code is causing lots of old vmalloc'ed areas to stay around, making new allocations slow. I wonder if its possible to make the caching of older areas less aggressive without reducing the beneficial effects of fewer TLB flushes?
Comment 6 Chuck Ebbert 2010-07-18 14:53:56 EDT
There is a patch in -mm that seems to fix this, but it doesn't seem to be going anywhere:

http://userweb.kernel.org/~akpm/mmotm/broken-out/mm-vmap-area-cache.patch
Comment 8 Bug Zapper 2010-07-30 07:18:27 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 9 Steve Whitehouse 2010-11-18 10:41:15 EST
Might as well close this since the upstream resolution is that we shouldn't be using vmalloc for any allocation where performance matters.

Note You need to log in before you can comment on or make changes to this bug.