From: Peter Zijlstra <peterz@infradead•org>
To: Jason Wang <jasowang@redhat•com>
Cc: "Michael S. Tsirkin" <mst@redhat•com>,
Mike Galbraith <umgwanakikbuti@gmail•com>,
davem@davemloft•net, netdev@vger•kernel.org,
linux-kernel@vger•kernel.org, Ingo Molnar <mingo@elte•hu>,
Eliezer Tamir <eliezer.tamir@linux•intel.com>
Subject: Re: [PATCH net-next 2/2] net: exit busy loop when another process is runnable
Date: Tue, 2 Sep 2014 12:24:10 +0200 [thread overview]
Message-ID: <20140902102410.GX27892@worktop.ger.corp.intel.com> (raw)
In-Reply-To: <5405419E.7020103@redhat.com>
On Tue, Sep 02, 2014 at 12:03:42PM +0800, Jason Wang wrote:
> On 09/01/2014 06:19 PM, Peter Zijlstra wrote:
> > OK I suppose that more or less makes sense, the contextual behaviour is
> > of course tedious in that it makes behaviour less predictable. The
> > 'other' tasks might not want to generate data and you then destroy
> > throughput by not spinning.
>
> The patch try to make sure:
> - the the performance of busy read was not worse than it was disabled in
> any cases.
> - the performance improvement of a single socket was not achieved by
> sacrificing the total performance (all other processes) of the system
>
> If 'other' tasks are also CPU or I/O intensive jobs, we switch to do
> them so the total performance were kept or even increased, and the
> performance of current process were guaranteed not worse than when busy
> read was disabled (or even better since it may still do busy read
> sometimes when it was the only runnable process). If 'other' task are
> not intensive, they just do little work and sleep soon, then the busy
> read can still work in most of the time during the future reads, we may
> still get obvious improvements.
Not entirely true; the select/poll whatever will now block, which means
we need a wakeup, which increases the latency immensely.
> > I'm not entirely sure I see how its all supposed to work though; the
> > various poll functions call sk_busy_poll() and do_select() also loops.
> >
> > The patch only kills the sk_busy_poll() loop, but then do_select() will
> > still loop and not sleep, so how is this helping?
>
> Yes, the patch only help for processes who did a blocking reads (busy
> read). For select(), maybe we can do the same thing but need more test
> and thoughts.
What's the blocking read callgraph, how so we end up in sk_busy_poll() there?
But that's another reason the patch is wrong.
next prev parent reply other threads:[~2014-09-02 10:24 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-21 8:05 [PATCH net-next 1/2] sched: introduce nr_running_this_cpu() Jason Wang
2014-08-21 8:05 ` [PATCH net-next 2/2] net: exit busy loop when another process is runnable Jason Wang
2014-08-21 8:11 ` Michael S. Tsirkin
2014-08-22 2:53 ` Jason Wang
2014-08-21 19:03 ` Amos Kong
2014-08-22 5:01 ` Mike Galbraith
2014-08-22 7:29 ` Jason Wang
2014-08-22 7:42 ` Ingo Molnar
2014-08-29 3:08 ` Jason Wang
2014-09-01 6:39 ` Eliezer Tamir
2014-09-02 3:29 ` Jason Wang
2014-09-02 6:15 ` Eliezer Tamir
2014-09-02 7:37 ` Jason Wang
2014-09-02 8:31 ` Michael S. Tsirkin
2014-09-03 6:49 ` Eliezer Tamir
2014-09-03 7:33 ` Jason Wang
2014-09-03 9:36 ` Peter Zijlstra
2014-09-03 9:59 ` Michael S. Tsirkin
2014-09-03 7:51 ` Michael S. Tsirkin
2014-09-04 6:51 ` Eliezer Tamir
2014-08-22 7:36 ` Ingo Molnar
2014-08-22 9:08 ` Jason Wang
2014-08-22 14:16 ` Eric Dumazet
2014-08-25 2:54 ` Jason Wang
2014-08-25 13:16 ` Eliezer Tamir
2014-08-26 7:16 ` Jason Wang
2014-09-01 6:55 ` Eliezer Tamir
2014-09-02 3:35 ` Jason Wang
2014-09-02 6:03 ` Eliezer Tamir
2014-09-02 6:31 ` Jason Wang
2014-09-03 6:21 ` Eliezer Tamir
2014-09-03 6:59 ` Jason Wang
2016-04-14 0:55 ` Peter Zijlstra
2014-09-03 8:09 ` Michael S. Tsirkin
2016-04-11 16:31 ` Michael S. Tsirkin
2016-04-13 7:20 ` Ingo Molnar
2016-04-13 13:28 ` Peter Zijlstra
2016-04-13 13:51 ` Michael S. Tsirkin
2016-04-14 0:58 ` Peter Zijlstra
2014-09-01 9:31 ` Peter Zijlstra
2014-09-01 9:52 ` Michael S. Tsirkin
2014-09-01 10:04 ` Peter Zijlstra
2014-09-01 10:19 ` Peter Zijlstra
2014-09-02 4:03 ` Jason Wang
2014-09-02 10:24 ` Peter Zijlstra [this message]
2014-09-03 6:58 ` Jason Wang
2014-09-03 9:30 ` Peter Zijlstra
2014-09-01 10:22 ` Michael S. Tsirkin
2014-09-02 3:38 ` Jason Wang
2014-09-02 6:12 ` Peter Zijlstra
2014-09-02 7:19 ` Jason Wang
2014-08-21 13:52 ` [PATCH net-next 1/2] sched: introduce nr_running_this_cpu() Ingo Molnar
2014-08-22 7:27 ` Jason Wang
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=20140902102410.GX27892@worktop.ger.corp.intel.com \
--to=peterz@infradead$(echo .)org \
--cc=davem@davemloft$(echo .)net \
--cc=eliezer.tamir@linux$(echo .)intel.com \
--cc=jasowang@redhat$(echo .)com \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=mingo@elte$(echo .)hu \
--cc=mst@redhat$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=umgwanakikbuti@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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