All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jonathan Tan <jonathantanmy@google.com>
Cc: Stefan Beller <sbeller@google.com>,
	"git\@vger.kernel.org" <git@vger.kernel.org>,
	Jonathan Nieder <jrnieder@gmail.com>
Subject: Re: [PATCH v2] fetch-pack: grow stateless RPC windows exponentially
Date: Tue, 19 Jul 2016 12:23:24 -0700	[thread overview]
Message-ID: <xmqq8twxfn4j.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <CAGf8dgL3t7uX7yAux0xc2QMJJdmnM0262Quj4o6gDehwA+4JqQ@mail.gmail.com> (Jonathan Tan's message of "Tue, 19 Jul 2016 12:03:24 -0700")

Jonathan Tan <jonathantanmy@google.com> writes:

>> So I guess what I do not understand is why we need to slow down the
>> exponential growth at all?
>
> The current code has an exponential (a' = a * 2) then a linear (a' = a
> + 1024) growth. I'm not slowing down the exponential growth - that
> part is retained. I'm replacing the linear growth with another
> conservative exponential growth (a' = a * 11 / 10).

As stateless-rpc mode is to drive a half-duplex channel, the
function essentially determines how many messages to buffer before
passing the control to the other side.  The increment between number
the function is called with and the function returns is how much the
other side is made to wait, i.e. how long the ping-pong latency is.

Even if it is conservative, I wonder if it is truly a good idea to
make it exponentially grow forever from that point of view.  Would
it give essentially the same result to you if we discard the patch
in question and just raise LARGE_FLUSH to 10k instead?


  parent reply	other threads:[~2016-07-19 19:23 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-18 18:36 [PATCH] fetch-pack: grow stateless RPC windows exponentially Jonathan Tan
2016-07-18 18:55 ` Jonathan Nieder
2016-07-18 19:10   ` Junio C Hamano
2016-07-18 19:16     ` Jonathan Tan
2016-07-18 19:31       ` Jonathan Nieder
2016-07-18 20:00         ` Junio C Hamano
2016-07-18 21:05           ` Jonathan Tan
2016-07-18 21:36             ` Junio C Hamano
2016-07-18 22:21               ` [PATCH v2] " Jonathan Tan
2016-07-18 22:40                 ` Jonathan Nieder
2016-07-19 16:46                 ` Stefan Beller
2016-07-19 19:03                   ` Jonathan Tan
2016-07-19 19:17                     ` Stefan Beller
2016-07-19 19:23                     ` Junio C Hamano [this message]
2016-07-19 19:53                       ` Jonathan Nieder
2016-07-19 20:20                         ` Junio C Hamano
2016-07-20 13:40                         ` Jeff King

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=xmqq8twxfn4j.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=jonathantanmy@google.com \
    --cc=jrnieder@gmail.com \
    --cc=sbeller@google.com \
    /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.