Bug 581459
| Summary: | vmalloc is slow | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Steve Whitehouse <swhiteho> | ||||||
| Component: | kernel | Assignee: | Rik van Riel <riel> | ||||||
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | low | ||||||||
| Version: | 14 | CC: | adas, anton, benl, bmarson, bmarzins, dougsland, dshaks, gansalmon, itamar, jonathan, kernel-maint, lwoodman, rpeterso | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | |||||||||
| : | 583026 (view as bug list) | Environment: | |||||||
| Last Closed: | 2010-11-18 15:41:15 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | 582522 | ||||||||
| Bug Blocks: | 583026, 619331 | ||||||||
| Attachments: |
|
||||||||
|
Description
Steve Whitehouse
2010-04-12 10:28:50 UTC
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
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...
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? 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 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 Might as well close this since the upstream resolution is that we shouldn't be using vmalloc for any allocation where performance matters. |