git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Carlo Marcelo Arenas Belón" <carenas@gmail.com>
Cc: git@vger.kernel.org, frekui@gmail.com,
	michael.osipov@siemens.com, ibrahim.vanak@hpe.com,
	matheus.bernardino@usp.br, vleschuk@accesssoftek.com
Subject: Re: [RFC PATCH 2/2] grep: make default number of threads reflect runtime
Date: Mon, 05 Aug 2019 14:28:31 -0700	[thread overview]
Message-ID: <xmqqa7cnmhds.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <20190804211509.39229-3-carenas@gmail.com> ("Carlo Marcelo Arenas Belón"'s message of "Sun, 4 Aug 2019 14:15:09 -0700")

Carlo Marcelo Arenas Belón  <carenas@gmail.com> writes:

> 5b594f457a (Threaded grep, 2010-01-25) added a hardcoded number of
> threads(8) to use in grep and 89f09dd34e (grep: add --threads=<num>
> option and grep.threads configuration, 2015-12-15) made it configurable
> through a knob as a workaround for systems where that default was not
> effective.
>
> Use instead the industry standard of 2x number of CPUs (to allow for
> IO wait) for the default.

Thanks.  

While I am not bold enough to endorse the "industry standard is
twice the number of CPUs" claim, my gut feeling agrees with you that
8 threads may be too many for a 2 CPU box.

I think we cap the parallelism to the number of CPUs (not twice
that) in all the codepaths that currently call online_cpus(), and
some codepaths even cap it further to avoid creating tasks that are
too small (e.g. name-hash, index-pack).

There may not be a single one-size-fits-all scaling factor (as I/O
bound jobs tend to do better with a bit more workers than there are
cores, but adding more workers would not help when you are CPU
bound), but we'd be better off to have a mechanism to allow us to
later have a consistent way to auto-scale the number of workers?

Random ideas include (not mutually exclusive)

 - accept "[grep] threads = 2xCPU", in addition to "[grep] threads =
   8", to mean "this many workers per CPUs"?

 - add "cpuBound.numThreads" and "ioBound.numThreads" variables to
   configure the number of workers for cpu and io bound jobs, so
   that the users do not have to configure them for each command?

 - build an num_threads() API that is used by the current callers of
   online_cpus(), including the new one this patch adds, perhaps
   with a signature allows it to take configuration key (e.g. "git
   grep" would pass "grep.threads") and if the task is expected to
   be IO or CPU bound ("git grep" may pass "I am heavy on IO"), e.g.

	int num_threads(const char *config_key,
			enum { CPUBOUND, IOBOUND } task_type);

   to hide the complexity of the first two items?

> Using Debian 10 amd64 in a 2 CPU VirtualBox running in macOS 10.14.6
> and that might had been representative of the original author environment
> shows an overall performance improvement by avoiding thread trashing:

The above does not parse very well, at least to me.

> diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt
> index 2d27969057..5d72e03b2e 100644
> --- a/Documentation/git-grep.txt
> +++ b/Documentation/git-grep.txt
> @@ -60,7 +60,7 @@ grep.extendedRegexp::
>  
>  grep.threads::
>  	Number of grep worker threads to use.  If unset (or set to 0),
> -	8 threads are used by default (for now).
> +	2 threads per core are used by default.
>  
>  grep.fullName::
>  	If set to true, enable `--full-name` option by default.
> diff --git a/builtin/grep.c b/builtin/grep.c
> index 580fd38f41..0ed8da30f8 100644
> --- a/builtin/grep.c
> +++ b/builtin/grep.c
> @@ -32,7 +32,6 @@ static char const * const grep_usage[] = {
>  
>  static int recurse_submodules;
>  
> -#define GREP_NUM_THREADS_DEFAULT 8
>  static int num_threads;
>  
>  static pthread_t *threads;
> @@ -1068,7 +1067,7 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
>  	} else if (num_threads < 0)
>  		die(_("invalid number of threads specified (%d)"), num_threads);
>  	else if (num_threads == 0)
> -		num_threads = HAVE_THREADS ? GREP_NUM_THREADS_DEFAULT : 1;
> +		num_threads = HAVE_THREADS ? online_cpus() * 2 : 1;
>  
>  	if (num_threads > 1) {
>  		if (!HAVE_THREADS)

      reply	other threads:[~2019-08-05 21:28 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-04 21:15 [RFC PATCH 0/2] grep: make threading smarter Carlo Marcelo Arenas Belón
2019-08-04 21:15 ` [RFC PATCH 1/2] p7810: add more grep performance relevant cases Carlo Marcelo Arenas Belón
2019-08-04 21:15 ` [RFC PATCH 2/2] grep: make default number of threads reflect runtime Carlo Marcelo Arenas Belón
2019-08-05 21:28   ` Junio C Hamano [this message]

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=xmqqa7cnmhds.fsf@gitster-ct.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=carenas@gmail.com \
    --cc=frekui@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=ibrahim.vanak@hpe.com \
    --cc=matheus.bernardino@usp.br \
    --cc=michael.osipov@siemens.com \
    --cc=vleschuk@accesssoftek.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.
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).