git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] fetch-pack: grow stateless RPC windows exponentially

From
Junio C Hamano <gitster@pobox.com>
Date
Jul 18, 2016, 19:10 UTC
Message-ID
<xmqq37n6kbib.fsf@gitster.mtv.corp.google.com>
In-Reply-To
<20160718185527.GB29326@google.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
Show 25 quoted lines
> Yay, thanks for this.
>
> When this condition triggers (count >= 10240), we have already
> experienced 10 rounds of negotiation.  Negotiation ought to have
> finished by then.  So this is a pretty conservative change to try to
> salvage an already bad situation.
>
> The condition ensures that the exponential growth will go faster
> than the previous heuristic of linear growth.
>
> Memory usage grows with the number of 'have's to be sent.  Linear
> growth didn't bound memory usage. This exponential growth makes memory
> usage increase faster, but not aggressively so and the unbounded
> memory usage is already something we'd want to address separately to
> handle hostile servers.
>
> All in all, this looks likely to allow negotiation to finish in fewer
> rounds, speeding up fetch, without much downside, so for what it's
> worth,
>
> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
>
> I'd expect us to need more aggressive improvements to negotiation in the
> end (e.g. finding a way to order SHA-1s sent as 'have's to finish in
> fewer rounds).  But this is a good start.  Thanks for writing it.

Sorry, while I agree with the general sentiment that the windowing heuristics can be improved, from your description, I would have expected an updated curve goes like "aggressive exponential -> conservative exponential -> slow linear", but the new comparison reads the other way around, i.e. "aggressive exponential -> slow linear -> conservative exponential".

I'd understand if it were more like "aggressive exponential -> conservative exponential" without linear phase when stateless_rpc is in use, though. I just do not quite understand the justification behind the order of three phases introduced by this change.

Show 13 quoted lines
>> diff --git a/fetch-pack.c b/fetch-pack.c
>> index b501d5c..3fcbda2 100644
>> --- a/fetch-pack.c
>> +++ b/fetch-pack.c
>> @@ -251,6 +251,8 @@ static int next_flush(struct fetch_pack_args *args, int count)
>>  
>>  	if (count < flush_limit)
>>  		count <<= 1;
>> +	else if (args->stateless_rpc && count >= flush_limit * 10)
>> +		count = count * 11 / 10;
>>  	else
>>  		count += flush_limit;
>>  	return count;
Previous: Jonathan NiederNext: Jonathan Tan
Message 3 of 17 in “fetch-pack: grow stateless RPC windows exponentially”
  1. fetch-pack: grow stateless RPC windows exponentiallyJonathan Tan, Jul 18, 2016
  2. Jonathan NiederJul 18, 2016
  3. Junio C HamanoJul 18, 2016
  4. Jonathan TanJul 18, 2016
  5. Jonathan NiederJul 18, 2016
  6. Junio C HamanoJul 18, 2016
  7. Jonathan TanJul 18, 2016
  8. Junio C HamanoJul 18, 2016
  9. fetch-pack: grow stateless RPC windows exponentiallyJonathan Tan, Jul 18, 2016
  10. Jonathan NiederJul 18, 2016
  11. Stefan BellerJul 19, 2016
  12. Jonathan TanJul 19, 2016
  13. Stefan BellerJul 19, 2016
  14. Junio C HamanoJul 19, 2016
  15. Jonathan NiederJul 19, 2016
  16. Junio C HamanoJul 19, 2016
  17. Jeff KingJul 20, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.