All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Derrick Stolee <stolee@gmail.com>
Cc: Ben Peart <peartben@gmail.com>,
	Thomas Gummerer <t.gummerer@gmail.com>,
	Git List <git@vger.kernel.org>
Subject: Re: Git Test Coverage Report (Tuesday, Sept 25)
Date: Thu, 27 Sep 2018 17:38:26 +0200	[thread overview]
Message-ID: <87wor7hrwt.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <07ab14bb-766b-e375-989b-73974ef7fece@gmail.com>


On Thu, Sep 27 2018, Derrick Stolee wrote:

> On 9/27/2018 11:21 AM, Ben Peart wrote:
>>
>>
>> On 9/26/2018 2:54 PM, Derrick Stolee wrote:
>>>
>>> GIT_TEST_INDEX_THREADS=1
>>>
>>
>> Because the test repos are so small (ie smaller than 10K files), the
>> test suite already executes as if GIT_TEST_INDEX_THREADS=1 is set
>> (ie single threaded). I added the test variable so that the
>> multi-threading code could be forced to execute in spite of the
>> default minimum number of files logic.
>>
>> I'd recommend you set GIT_TEST_INDEX_THREADS=3 instead. (3 because 1
>> thread is used for loading the index extensions and we need 2 or
>> more threads available to exercise multi-threaded loading of the
>> index entries).
>
> According to t/README, GIT_TEST_INDEX_THREADS is a boolean and setting
> it to 1 causes us to use 3 threads:
>
>  GIT_TEST_INDEX_THREADS=<boolean> forces multi-threaded loading of
>  the index cache entries and extensions for the whole test suite.
>
> Here is the only consumption of the variable in the product code (in
> read-cache.c):
>
>  /* enable testing with fewer than default minimum of entries */
>  if (istate->cache_nr > 1 && nr_threads < 3 &&
> git_env_bool("GIT_TEST_INDEX_THREADS", 0))
>  nr_threads = 3;
>
> This was non-obvious to me, and I had originally set it to a larger
> number. I happened to notice the boolean nature while I was looking up
> the rest of the GIT_TEST_* variables.

I didn't know it worked like that. Would be neat if we had some "strict
bool" function in config.c that would accept on/true/1 off/false/0 but
barf on e.g. 12345 instead of treating it as just another synonym for 1,
I'd say we could even enable it by default, but maybe not, but
definitely for all this GIT_TEST_* stuff.

  reply	other threads:[~2018-09-27 15:38 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-25 18:42 Git Test Coverage Report (Tuesday, Sept 25) Derrick Stolee
2018-09-25 21:12 ` Ben Peart
2018-09-26 10:43   ` Derrick Stolee
2018-09-26 10:56     ` Jason Pyeron
2018-09-26 11:03       ` Derrick Stolee
2018-09-26 18:43     ` Thomas Gummerer
2018-09-26 18:54       ` Derrick Stolee
2018-09-27 15:21         ` Ben Peart
2018-09-27 15:28           ` Derrick Stolee
2018-09-27 15:38             ` Ævar Arnfjörð Bjarmason [this message]
2018-09-26 17:59 ` Junio C Hamano
2018-09-26 18:44   ` Derrick Stolee
2018-09-27 15:14     ` Ben Peart
2018-09-27 15:16       ` Derrick Stolee
2018-09-26 18:58 ` Elijah Newren

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=87wor7hrwt.fsf@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=peartben@gmail.com \
    --cc=stolee@gmail.com \
    --cc=t.gummerer@gmail.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.