From: <yang.yang29@zte.com.cn>
To: <kuba@kernel.org>
Cc: <davem@davemloft.net>, <edumazet@google.com>, <pabeni@redhat.com>,
<bigeasy@linutronix.de>, <imagedong@tencent.com>,
<kuniyu@amazon.com>, <petrm@nvidia.com>, <liu3101@purdue.edu>,
<wujianguo@chinatelecom.cn>, <netdev@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <tedheadster@gmail.com>
Subject: Re: [PATCH linux-next] net: record times of netdev_budget exhausted
Date: Tue, 6 Dec 2022 10:35:07 +0800 (CST) [thread overview]
Message-ID: <202212061035074041030@zte.com.cn> (raw)
In-Reply-To: <20221205175314.0487527a@kernel.org>
On Tue, 6 Dec 2022 09:53:05 +0800 (CST) kuba@kernel.org wrote:
> time_squeeze is extremely noisy and annoyingly useless,
> we need to understand exactly what you're doing before
> we accept any changes to this core piece of code.
The author of "Replace 2 jiffies with sysctl netdev_budget_usecs
to enable softirq tuning" is Matthew Whitehead, he said this in
git log: Constants used for tuning are generally a bad idea, especially
as hardware changes over time...For example, a very fast machine
might tune this to 1000 microseconds, while my regression testing
486DX-25 needs it to be 4000 microseconds on a nearly idle network
to prevent time_squeeze from being incremented.
And on my systems there are huge packets on the intranet, and we
came accross with lots of time_squeeze. The idea is that, netdev_budget*
are selections between throughput and real-time. If we care throughput
and not care real-time so much, we may want bigger netdev_budget*.
In this scenario, we want to tune netdev_budget* and see their effect
separately.
By the way, if netdev_budget* are useless, should they be deleted?
Thanks.
next prev parent reply other threads:[~2022-12-06 2:35 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-03 8:12 [PATCH linux-next] net: record times of netdev_budget exhausted yang.yang29
2022-12-03 10:06 ` kernel test robot
2022-12-03 16:50 ` kernel test robot
2022-12-03 16:50 ` kernel test robot
2022-12-06 1:53 ` Jakub Kicinski
2022-12-06 2:35 ` yang.yang29 [this message]
2022-12-06 2:47 ` Jakub Kicinski
2022-12-07 7:27 ` yang.yang29
2022-12-07 7:58 ` Eric Dumazet
2022-12-07 8:17 ` yang.yang29
2022-12-07 23:28 ` Jakub Kicinski
2022-12-07 12:30 ` yang.yang29
2022-12-07 23:32 ` Jakub Kicinski
2022-12-08 1:12 ` yang.yang29
2022-12-08 1:23 ` Jakub Kicinski
2022-12-08 1:42 ` yang.yang29
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=202212061035074041030@zte.com.cn \
--to=yang.yang29@zte.com.cn \
--cc=bigeasy@linutronix.de \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=imagedong@tencent.com \
--cc=kuba@kernel.org \
--cc=kuniyu@amazon.com \
--cc=linux-kernel@vger.kernel.org \
--cc=liu3101@purdue.edu \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=petrm@nvidia.com \
--cc=tedheadster@gmail.com \
--cc=wujianguo@chinatelecom.cn \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.