git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jonathan Tan <jonathantanmy@google.com>
Cc: git@vger.kernel.org, peff@peff.net, jrnieder@gmail.com
Subject: Re: [PATCH 1/2] fetch-pack: in protocol v2, in_vain only after ACK
Date: Fri, 24 Apr 2020 22:08:26 -0700	[thread overview]
Message-ID: <xmqqlfmk9mph.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <51174e53527f9b29bb0a5ebb8726f07333113dfb.1587775989.git.jonathantanmy@google.com> (Jonathan Tan's message of "Fri, 24 Apr 2020 17:56:01 -0700")

Jonathan Tan <jonathantanmy@google.com> writes:

> When fetching, Git stops negotiation when it has sent at least
> MAX_IN_VAIN (which is 256) "have" lines without having any of them
> ACK-ed. But this is supposed to trigger only after the first ACK, as
> pack-protocol.txt says:
>
>   However, the 256 limit *only* turns on in the canonical client
>   implementation if we have received at least one "ACK %s continue"
>   during a prior round.  This helps to ensure that at least one common
>   ancestor is found before we give up entirely.
>
> The code path for protocol v0 observes this, but not protocol v2,
> resulting in shorter negotiation rounds but significantly larger
> packfiles. Teach the code path for protocol v2 to check this criterion
> only after at least one ACK was received.

Makes sense.

I think we can instead use in_vain==NULL as a signal that we haven't
seen any ack yet and that shrinks the patch somewhat ([Patch 1/2]
becomes +6/-4 from +9/-4 for fetch-pack.c).  I do not know if the
result is easier to follow (as there is one less variable to keep in
mind), though.  The callee is probably easier to reason about (it
needs to worry about the *in_vain variable only when it is given---
you cannot beat the simplicity of it), but the caller side may
become harder to reason about, especially without any comment where
in_vain_p becomes non-NULL.  Your version has an assignment to make
"seen_ack" to true there, which makes it very clear without any
comment what is going on.

So I dunno.  I've queued your version and discarded the following.

 fetch-pack.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/fetch-pack.c b/fetch-pack.c
index 1734a573b0..7b837b6a76 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -1156,8 +1156,9 @@ static int add_haves(struct fetch_negotiator *negotiator,
 			break;
 	}
 
-	*in_vain += haves_added;
-	if (!haves_added || *in_vain >= MAX_IN_VAIN) {
+	if (in_vain)
+		*in_vain += haves_added;
+	if (!haves_added || (in_vain && *in_vain >= MAX_IN_VAIN)) {
 		/* Send Done */
 		packet_buf_write(req_buf, "done\n");
 		ret = 1;
@@ -1444,6 +1445,7 @@ static struct ref *do_fetch_pack_v2(struct fetch_pack_args *args,
 	int haves_to_send = INITIAL_FLUSH;
 	struct fetch_negotiator negotiator_alloc;
 	struct fetch_negotiator *negotiator;
+	int *in_vain_p = NULL;
 
 	if (args->no_dependents) {
 		negotiator = NULL;
@@ -1499,7 +1501,7 @@ static struct ref *do_fetch_pack_v2(struct fetch_pack_args *args,
 			}
 			if (send_fetch_request(negotiator, fd[1], args, ref,
 					       &common,
-					       &haves_to_send, &in_vain,
+					       &haves_to_send, in_vain_p,
 					       reader.use_sideband))
 				state = FETCH_GET_PACK;
 			else
@@ -1512,7 +1514,7 @@ static struct ref *do_fetch_pack_v2(struct fetch_pack_args *args,
 				state = FETCH_GET_PACK;
 				break;
 			case 1:
-				in_vain = 0;
+				in_vain_p = &in_vain;
 				/* fallthrough */
 			default:
 				state = FETCH_SEND_REQUEST;

  reply	other threads:[~2020-04-25  5:13 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-25  0:56 [PATCH 0/2] Protocol v2 in_vain fixes Jonathan Tan
2020-04-25  0:56 ` [PATCH 1/2] fetch-pack: in protocol v2, in_vain only after ACK Jonathan Tan
2020-04-25  5:08   ` Junio C Hamano [this message]
2020-04-26  0:28   ` Jonathan Nieder
2020-04-27 17:27     ` Jonathan Tan
2020-04-27 22:16       ` Junio C Hamano
2020-04-25  0:56 ` [PATCH 2/2] fetch-pack: in protocol v2, reset in_vain upon ACK Jonathan Tan
2020-04-26  1:10   ` Jonathan Nieder
2020-04-27 17:28     ` Jonathan Tan
2020-04-28  0:01 ` [PATCH v2 0/3] Protocol v2 in_vain fixes Jonathan Tan
2020-04-28  0:01   ` [PATCH v2 1/3] fetch-pack: return enum from process_acks() Jonathan Tan
2020-04-28  0:53     ` Jonathan Nieder
2020-04-28 16:54       ` Junio C Hamano
2020-04-28 18:00         ` Michal Suchánek
2020-04-28 19:17           ` Junio C Hamano
2020-04-28  0:01   ` [PATCH v2 2/3] fetch-pack: in protocol v2, in_vain only after ACK Jonathan Tan
2020-04-28  0:54     ` Jonathan Nieder
2020-05-06 21:08     ` Johannes Schindelin
2020-05-06 22:07       ` [PATCH] t5500: count objects through stderr, not trace Jonathan Tan
2020-05-06 22:28         ` Junio C Hamano
2020-05-06 22:40           ` Junio C Hamano
2020-05-07 14:35         ` Johannes Schindelin
2020-10-13 14:45         ` Johannes Schindelin
2020-04-28  0:01   ` [PATCH v2 3/3] fetch-pack: in protocol v2, reset in_vain upon ACK Jonathan Tan
2020-04-28  0:55     ` Jonathan Nieder

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqlfmk9mph.fsf@gitster.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=jonathantanmy@google.com \
    --cc=jrnieder@gmail.com \
    --cc=peff@peff.net \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).