From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.7 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_PASS, USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DC45CC282C4 for ; Tue, 22 Jan 2019 21:18:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A5C9820870 for ; Tue, 22 Jan 2019 21:18:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1548191939; bh=lGlZqFH9Y30dJk7kbhuQDBeOgwMAnwPsidrr8GoUYy0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=XdnsTltPL5+/9JMUm/JhQ18KclYnzibOctCQP/mg8KyCNmkYKSGWR+W+tn2htmZ7U +PLToKqzxA25Mzipc/f6iab7c5+FpdAMQlCNDFlLpxqzZPEJUj8MhHlNlsKtPqsyea ErkdWIfPP5dWIf+V0+QlgcdzJItDUlqtMGy8u/0o= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726979AbfAVVS6 (ORCPT ); Tue, 22 Jan 2019 16:18:58 -0500 Received: from mail-yw1-f44.google.com ([209.85.161.44]:41070 "EHLO mail-yw1-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726948AbfAVVS5 (ORCPT ); Tue, 22 Jan 2019 16:18:57 -0500 Received: by mail-yw1-f44.google.com with SMTP id f65so10032569ywc.8 for ; Tue, 22 Jan 2019 13:18:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=C0gU5+LIrhqsHOWv+PdN/H3u4UOaAi+0hmQaRjFiJgc=; b=HAsEkMERUGS1qqyizYgC5Qy39fDnjeZIqStRU8UHIUQEEGZcL7kMTCqPXH6Fg4kbYH ZoLaT2ZtdnNwlHN2kul9IAimxOXcj7qTBTIB8iuqzbfL8sxhcnfLJCwTTwD3oaR5xA9h jpL69k7mJAMvhdGi4OfpfvauzmMU4LAqXvLa6YuCIVEPWF0u/lGBpu/J71tHrJb+y8Mu W8mt2Mt6YXPNlcoZ55VZ1DB6x9S4im3flmIkqQcF9HWGDcoAv/ayzeuMrBVcBzcR0XV4 v4xVDtcS8xRtUagxq/UtN3eyvkxglDnM+nb17ZrW2AMK59/JIcQRMD8zwDKivfOFqslD PvIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=C0gU5+LIrhqsHOWv+PdN/H3u4UOaAi+0hmQaRjFiJgc=; b=F+swXqNEBrbL7mJ6zfWplhxEWXyYTw3+HEM7l48pPxAZPMdffC5Bktxtu8xaz92bqw u7h+FS6KDh9i6IlqL5cuNc/Dx2sVphXxHelPwoyWZQhL5TieNRpq37XuJheYwywUGb+F 7FuyinCVVbyzdThgtiiuAH3US2NY/slGEmtkbqU/JLF3M0KkHjQ/nV1p/veRtyb/sjbx DYXxv3vgt0R3x12FRWggsOGZmJxtleXnggcFqdPLxyXXxVecDif5co2FVrfg/EP8Agk3 ifYqSpxlhK9bnrHE/sMVVOwzJiC4TzCD+ZPTApU6bdgspQz7pM1PWTV+VkiOVvBzNqKL J6Kg== X-Gm-Message-State: AJcUukcX9wnjM0qE2sq00JW4OQt85wrhF/Wip2VIGgrXfQ3Rd5wxBw4O CGIOLo6UbSf03AvC5KfLwnE= X-Google-Smtp-Source: ALg8bN6kjYeGAgkJGhxQcNvTqUbue8n+AFCNXkUnugoLRyu98bJ4auxdYIMjVbKT9NEbq+pFkxR9Wg== X-Received: by 2002:a0d:e8d7:: with SMTP id r206mr34142493ywe.183.1548191936513; Tue, 22 Jan 2019 13:18:56 -0800 (PST) Received: from localhost ([2620:10d:c091:200::4:a19d]) by smtp.gmail.com with ESMTPSA id b144sm11640816ywa.33.2019.01.22.13.18.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Jan 2019 13:18:55 -0800 (PST) Date: Tue, 22 Jan 2019 13:18:53 -0800 From: Tejun Heo To: Eric Dumazet Cc: Vlad Buslov , Dennis Zhou , Linux Kernel Network Developers , Yevgeny Kliteynik , Yossef Efraim , Maor Gottlieb Subject: Re: tc filter insertion rate degradation Message-ID: <20190122211853.GF50184@devbig004.ftw2.facebook.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Hello, On Tue, Jan 22, 2019 at 09:33:10AM -0800, Eric Dumazet wrote: > > 1) Before: > > > > Samples: 63K of event 'cycles:ppp', Event count (approx.): 48796480071 > > Children Self Co Shared Object Symbol > > + 21.19% 3.38% tc [kernel.vmlinux] [k] pcpu_alloc > > + 3.45% 0.25% tc [kernel.vmlinux] [k] pcpu_alloc_area > > > > 2) After: > > > > Samples1: 92K of event 'cycles:ppp', Event count (approx.): 71446806550 > > Children Self Co Shared Object Symbol > > + 44.67% 3.99% tc [kernel.vmlinux] [k] pcpu_alloc > > + 19.25% 0.22% tc [kernel.vmlinux] [k] pcpu_alloc_area The allocator hint only remembers the max available size per chunk but not the alignment, so depending on the allocation pattern, alignment requirement change can lead to way more scanning per alloc attempt. Shouldn't be too difficult to improve tho. > I guess this is more a question for per-cpu allocator experts / maintainers ? > > 16-bytes alignment for 16-bytes objects sound quite reasonable [1] > > It also means that if your workload is mostly being able to setup / > dismantle tc filters, > instead of really using them, you might go back to atomics instead of > expensive per cpu storage. > > (Ie optimize control path instead of data path) > > Thanks ! > > [1] We even might make this generic as in : > > diff --git a/mm/percpu.c b/mm/percpu.c > index 27a25bf1275b7233d28cc0b126256e0f8a2b7f4f..bbf4ad37ae893fc1da5523889dd147f046852cc7 > 100644 > --- a/mm/percpu.c > +++ b/mm/percpu.c > @@ -1362,7 +1362,11 @@ static void __percpu *pcpu_alloc(size_t size, > size_t align, bool reserved, > */ > if (unlikely(align < PCPU_MIN_ALLOC_SIZE)) > align = PCPU_MIN_ALLOC_SIZE; > - > + while (align < L1_CACHE_BYTES && (align << 1) <= size) { > + if (size % (align << 1)) > + break; > + align <<= 1; > + } Percpu storage is expensive and cache line sharing tends to be less of a problem (cuz they're per-cpu), so it is useful to support custom alignments for tighter packing. Thanks. -- tejun