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=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS 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 0F3AAC282C4 for ; Wed, 13 Feb 2019 00:42:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D279C206C2 for ; Wed, 13 Feb 2019 00:42:10 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="XmuKYExk" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730642AbfBMAmJ (ORCPT ); Tue, 12 Feb 2019 19:42:09 -0500 Received: from mail-pf1-f193.google.com ([209.85.210.193]:46896 "EHLO mail-pf1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727871AbfBMAmJ (ORCPT ); Tue, 12 Feb 2019 19:42:09 -0500 Received: by mail-pf1-f193.google.com with SMTP id g6so271163pfh.13 for ; Tue, 12 Feb 2019 16:42:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=bzN9qow9eVreez8gi2S1bdvF2CH7Rv854ZU1Kmw+rGA=; b=XmuKYExk/76AfD5qkP60uItaBYE3+eh9uQ5XYzWEed8uhaoZU0+R7fSTRt7vWWGzGd SyqkynOLHeLy4q8Krqb02GdCCYl7MzDxo0HmJGtpp764GKkwXAg2PNKyGXxNUKAL1hCQ ooM5T8jn0y2E7U2TryijafMuyg3H12esv6k9bnwd45sLZpxe3ChMVOx7tgUz3dr5l8YJ mXuzx7NKrcse1T/ndcy81jAOjcfn65bLuZZ6bt0P4c2EKESY7qOJV4muH1EVyjdujMo4 a5I7JE+0zO1fMR6YuIVsBVBxR/LaYDkTR3o+zuDW8/MeL5+pcjhrpJU21kKPZCcOlfhP uyLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=bzN9qow9eVreez8gi2S1bdvF2CH7Rv854ZU1Kmw+rGA=; b=BjJnR33IFCQ/hKrDi8SUSOB8RZtb9BhtAu1cxHATl3ksOHva1gtgX8LyO+oCyh4MHm gXylgg08fyDXHh7oNMOP24LlQTd00POQUO8q3+vxVXV8j92HPVyaig6LND29mxSG/geg hDX8RfYGq7tl6sX9Q4Dpsx5TrHdfCFLw487gxJsDx+CjeoHutMC/6gLZJbURrshs9T88 uFs3xWIAMFsACtNanfn/bqCMx1J9jwZc5hxHXoifJSYRISFPjo2BVG0c6n53Mit8+5tR Piub0ExnA3HHFS3xG2PG+t5bJcRfHB0Fl/Dr04s6wOEFoG9NZfWjmPKojJMe4qlH/hUa k31A== X-Gm-Message-State: AHQUAuZGAhbU6YfX272lrQ+/qJ2S/5W1wIFt3QaFh86hpkvZNZa4oz/J I4Xtn6gU+A2fi6Z+vuk/rmw= X-Google-Smtp-Source: AHgI3Iaaap05EId5vtktIHf5F59ypw95mbqUG/TLEwU0myIfKvT3w4ydy3db0zf5X/e+zo+0YBg6KQ== X-Received: by 2002:a63:9144:: with SMTP id l65mr4362583pge.396.1550018528769; Tue, 12 Feb 2019 16:42:08 -0800 (PST) Received: from [192.168.88.100] (ip-24-221-53-235.brbnca.spcsdns.net. [24.221.53.235]) by smtp.gmail.com with ESMTPSA id u2sm2669840pfh.134.2019.02.12.16.42.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Feb 2019 16:42:07 -0800 (PST) Subject: Re: [PATCH iproute2 net-next v2 3/4] ss: Buffer raw fields first, then render them as a table To: Stefano Brivio , Stephen Hemminger Cc: netdev@vger.kernel.org, Sabrina Dubroca References: From: Eric Dumazet Message-ID: <82f1bc98-df6d-2b0a-17e5-fa057563284e@gmail.com> Date: Tue, 12 Feb 2019 16:42:04 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 12/11/2017 04:46 PM, Stefano Brivio wrote: > This allows us to measure the maximum field length for each > column before printing fields and will permit us to apply > optimal field spacing and distribution. Structure of the output > buffer with chunked allocation is described in comments. > > Output is still unchanged, original spacing is used. > > Running over one million sockets with -tul options by simply > modifying main() to loop 50,000 times over the *_show() > functions, buffering the whole output and rendering it at the > end, with 10 UDP sockets, 10 TCP sockets, while throwing > output away, doesn't show significant changes in execution time > on my laptop with an Intel i7-6600U CPU: > > - before this patch: > $ time ./ss -tul > /dev/null > real 0m29.899s > user 0m2.017s > sys 0m27.801s > > - after this patch: > $ time ./ss -tul > /dev/null > real 0m29.827s > user 0m1.942s > sys 0m27.812s > I do not get it. "ss -emoi " uses almost 1KB per socket. 10,000,000 sockets -> we need about 10GB of memory ??? This is a serious regression.