From: Leonard Crestez <lcrestez@ixiacom.com>
To: Tejun Heo <tj@kernel.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Christoph Lameter <cl@linux-foundation.org>,
Sorin Dumitru <sdumitru@ixiacom.com>
Subject: Re: [RFC v2] percpu: Add a separate function to merge free areas
Date: Thu, 4 Dec 2014 22:10:18 +0200 [thread overview]
Message-ID: <5480BFAA.2020106@ixiacom.com> (raw)
In-Reply-To: <20141204175713.GE2995@htj.dyndns.org>
On 12/04/2014 07:57 PM, Tejun Heo wrote:
> Hello,
>
> On Wed, Dec 03, 2014 at 12:33:59AM +0200, Leonard Crestez wrote:
>> It seems that free_percpu performance is very bad when working with small
>> objects. The easiest way to reproduce this is to allocate and then free a large
>> number of percpu int counters in order. Small objects (reference counters and
>> pointers) are common users of alloc_percpu and I think this should be fast.
>> This particular issue can be encountered with very large number of net_device
>> structs.
>
> Do you actually experience this with an actual workload? The thing is
> allocation has the same quadratic complexity. If this is actually an
> issue (which can definitely be the case), I'd much prefer implementing
> a properly scalable area allocator than mucking with the current
> implementation.
Yes, we are actually experiencing issues with this. We create lots of virtual
net_devices and routes, which means lots of percpu counters/pointers. In particular
we are getting worse performance than in older kernels because the net_device refcnt
is now a percpu counter. We could turn that back into a single integer but this
would negate an upstream optimization.
We are working on top of linux_3.10. We already pulled some allocation optimizations.
At least for simple allocation patterns pcpu_alloc does not appear to be unreasonably
slow.
Having a "properly scalable" percpu allocator would be quite nice indeed.
Regards,
Leonard
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2014-12-04 20:10 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-02 22:33 Leonard Crestez
2014-12-04 17:57 ` Tejun Heo
2014-12-04 20:10 ` Leonard Crestez [this message]
2014-12-04 20:28 ` Christoph Lameter
2014-12-04 20:45 ` Tejun Heo
2014-12-04 20:52 ` Al Viro
2014-12-04 21:15 ` Christoph Lameter
2014-12-04 21:19 ` Tejun Heo
2014-12-04 21:20 ` Christoph Lameter
2014-12-05 6:25 ` Konstantin Khlebnikov
2014-12-04 20:42 ` Tejun Heo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5480BFAA.2020106@ixiacom.com \
--to=lcrestez@ixiacom.com \
--cc=cl@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=sdumitru@ixiacom.com \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox