[v3,10/19] unpack-trees: add basic support for parallel checkout

Commit Message

Matheus Tavares Oct. 29, 2020, 2:14 a.m. UTC

This new interface allows us to enqueue some of the entries being
checked out to later call write_entry() for them in parallel. For now,
the parallel checkout machinery is enabled by default and there is no
user configuration, but run_parallel_checkout() just writes the queued
entries in sequence (without spawning additional workers). The next
patch will actually implement the parallelism and, later, we will make
it configurable.

When there are path collisions among the entries being written (which
can happen e.g. with case-sensitive files in case-insensitive file
systems), the parallel checkout code detects the problem and marks the
item with PC_ITEM_COLLIDED. Later, these items are sequentially fed to
checkout_entry() again. This is similar to the way the sequential code
deals with collisions, overwriting the previously checked out entries
with the subsequent ones. The only difference is that, when we start
writing the entries in parallel, we won't be able to determine which of
the colliding entries will survive on disk (for the sequential
algorithm, it is always the last one).

I also experimented with the idea of not overwriting colliding entries,
and it seemed to work well in my simple tests. However, because just one
entry of each colliding group would be actually written, the others
would have null lstat() fields on the index. This might not be a problem
by itself, but it could cause performance penalties for subsequent
commands that need to refresh the index: when the st_size value cached
is 0, read-cache.c:ie_modified() will go to the filesystem to see if the
contents match. As mentioned in the function:

    * Immediately after read-tree or update-index --cacheinfo,
    * the length field is zero, as we have never even read the
    * lstat(2) information once, and we cannot trust DATA_CHANGED
    * returned by ie_match_stat() which in turn was returned by
    * ce_match_stat_basic() to signal that the filesize of the
    * blob changed.  We have to actually go to the filesystem to
    * see if the contents match, and if so, should answer "unchanged".

So, if we have N entries in a colliding group and we decide to write and
lstat() only one of them, every subsequent git-status will have to read,
convert, and hash the written file N - 1 times, to check that the N - 1
unwritten entries are dirty. By checking out all colliding entries (like
the sequential code does), we only pay the overhead once.

Co-authored-by: Nguyễn Thái Ngọc Duy <[e-mail]>
Co-authored-by: Jeff Hostetler <[e-mail]>
Signed-off-by: Matheus Tavares <[e-mail]>
---
 Makefile            |   1 +
 entry.c             |  17 +-
 parallel-checkout.c | 368 ++++++++++++++++++++++++++++++++++++++++++++
 parallel-checkout.h |  27 ++++
 unpack-trees.c      |   6 +-
 5 files changed, 416 insertions(+), 3 deletions(-)
 create mode 100644 parallel-checkout.c
 create mode 100644 parallel-checkout.h

Comments

Junio C Hamano Nov. 2, 2020, 7:35 p.m. UTC | #1

Matheus Tavares <[e-mail]> writes:

> This new interface allows us to enqueue some of the entries being
> checked out to later call write_entry() for them in parallel. For now,
> the parallel checkout machinery is enabled by default and there is no
> user configuration, but run_parallel_checkout() just writes the queued
> entries in sequence (without spawning additional workers).

In other words, this would show the worst case overhead caused by
the framework to allow parallel checkout, relative to the current
code.  Which is quite a sensible and separate step to have in the
series.  I like it.

> The next
> patch will actually implement the parallelism and, later, we will make
> it configurable.

OK.

> When there are path collisions among the entries being written (which
> can happen e.g. with case-sensitive files in case-insensitive file
> systems), the parallel checkout code detects the problem and marks the
> item with PC_ITEM_COLLIDED. Later, these items are sequentially fed to
> checkout_entry() again. This is similar to the way the sequential code
> deals with collisions, overwriting the previously checked out entries
> with the subsequent ones. The only difference is that, when we start
> writing the entries in parallel, we won't be able to determine which of
> the colliding entries will survive on disk (for the sequential
> algorithm, it is always the last one).

Sure.  "The last one" determinism does not buy us very much, but it
is prudent to keep such a behavioural difference in mind.

> I also experimented with the idea of not overwriting colliding entries,
> and it seemed to work well in my simple tests. However, because just one
> entry of each colliding group would be actually written, the others
> would have null lstat() fields on the index. This might not be a problem
> by itself, but it could cause performance penalties for subsequent
> commands that need to refresh the index: when the st_size value cached
> is 0, read-cache.c:ie_modified() will go to the filesystem to see if the
> contents match. As mentioned in the function:
>
>     * Immediately after read-tree or update-index --cacheinfo,
>     * the length field is zero, as we have never even read the
>     * lstat(2) information once, and we cannot trust DATA_CHANGED
>     * returned by ie_match_stat() which in turn was returned by
>     * ce_match_stat_basic() to signal that the filesize of the
>     * blob changed.  We have to actually go to the filesystem to
>     * see if the contents match, and if so, should answer "unchanged".
>
> So, if we have N entries in a colliding group and we decide to write and
> lstat() only one of them, every subsequent git-status will have to read,
> convert, and hash the written file N - 1 times, to check that the N - 1
> unwritten entries are dirty. By checking out all colliding entries (like
> the sequential code does), we only pay the overhead once.

And the cost is to writing them out N times is not free, either, I
presume?

But I do not see the point of wasting engineering effort by trying
to make it more efficient to create a corrupt working tree that is
unusable because some paths that ought to exist are missing, so I
think it is OK.

> Co-authored-by: Nguyễn Thái Ngọc Duy <[e-mail]>
> Co-authored-by: Jeff Hostetler <[e-mail]>
> Signed-off-by: Matheus Tavares <[e-mail]>
> ---
>  Makefile            |   1 +
>  entry.c             |  17 +-
>  parallel-checkout.c | 368 ++++++++++++++++++++++++++++++++++++++++++++
>  parallel-checkout.h |  27 ++++
>  unpack-trees.c      |   6 +-
>  5 files changed, 416 insertions(+), 3 deletions(-)
>  create mode 100644 parallel-checkout.c
>  create mode 100644 parallel-checkout.h
>
> diff --git a/Makefile b/Makefile
> index 1fb0ec1705..10ee5e709b 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -945,6 +945,7 @@ LIB_OBJS += pack-revindex.o
>  LIB_OBJS += pack-write.o
>  LIB_OBJS += packfile.o
>  LIB_OBJS += pager.o
> +LIB_OBJS += parallel-checkout.o
>  LIB_OBJS += parse-options-cb.o
>  LIB_OBJS += parse-options.o
>  LIB_OBJS += patch-delta.o
> diff --git a/entry.c b/entry.c
> index 9d79a5671f..6676954431 100644
> --- a/entry.c
> +++ b/entry.c
> @@ -7,6 +7,7 @@
>  #include "progress.h"
>  #include "fsmonitor.h"
>  #include "entry.h"
> +#include "parallel-checkout.h"
>  
>  static void create_directories(const char *path, int path_len,
>  			       const struct checkout *state)
> @@ -426,8 +427,17 @@ static void mark_colliding_entries(const struct checkout *state,
>  	for (i = 0; i < state->istate->cache_nr; i++) {
>  		struct cache_entry *dup = state->istate->cache[i];
>  
> -		if (dup == ce)
> -			break;
> +		if (dup == ce) {
> +			/*
> +			 * Parallel checkout creates the files in no particular
> +			 * order. So the other side of the collision may appear
> +			 * after the given cache_entry in the array.
> +			 */
> +			if (parallel_checkout_status() == PC_RUNNING)
> +				continue;
> +			else
> +				break;
> +		}
>  
>  		if (dup->ce_flags & (CE_MATCHED | CE_VALID | CE_SKIP_WORKTREE))
>  			continue;
> @@ -536,6 +546,9 @@ int checkout_entry_ca(struct cache_entry *ce, struct conv_attrs *ca,
>  		ca = &ca_buf;
>  	}
>  
> +	if (!enqueue_checkout(ce, ca))
> +		return 0;
> +
>  	return write_entry(ce, path.buf, ca, state, 0);

It it is not wrong but feels strange that paths that cannot be
handled by parallel codepath for whatever reason are written using
the fallback code, but the fallback actually touches the disk before
the queued paths for parallel writeout ;-) What's the reason why
some paths cannot be handled by the new codepath again?  Also, can a
path that is handled by the fallback code collide with other paths
that are handled by the parallel codepath, and what happens for
these paths?

>  }
>  
> diff --git a/parallel-checkout.c b/parallel-checkout.c
> new file mode 100644
> index 0000000000..981dbe6ff3
> --- /dev/null
> +++ b/parallel-checkout.c
> @@ -0,0 +1,368 @@
> +#include "cache.h"
> +#include "entry.h"
> +#include "parallel-checkout.h"
> +#include "streaming.h"
> +
> +enum pc_item_status {
> +	PC_ITEM_PENDING = 0,
> +	PC_ITEM_WRITTEN,
> +	/*
> +	 * The entry could not be written because there was another file
> +	 * already present in its path or leading directories. Since
> +	 * checkout_entry_ca() removes such files from the working tree before
> +	 * enqueueing the entry for parallel checkout, it means that there was
> +	 * a path collision among the entries being written.
> +	 */
> +	PC_ITEM_COLLIDED,
> +	PC_ITEM_FAILED,
> +};
> +
> +struct parallel_checkout_item {
> +	/* pointer to a istate->cache[] entry. Not owned by us. */
> +	struct cache_entry *ce;
> +	struct conv_attrs ca;
> +	struct stat st;
> +	enum pc_item_status status;
> +};
> +
> +struct parallel_checkout {
> +	enum pc_status status;
> +	struct parallel_checkout_item *items;
> +	size_t nr, alloc;
> +};
> +
> +static struct parallel_checkout parallel_checkout = { 0 };

Can't we let this handled by BSS by not explicitly giving an initial
value?

> +enum pc_status parallel_checkout_status(void)
> +{
> +	return parallel_checkout.status;
> +}
> +
> +void init_parallel_checkout(void)
> +{
> +	if (parallel_checkout.status != PC_UNINITIALIZED)
> +		BUG("parallel checkout already initialized");
> +
> +	parallel_checkout.status = PC_ACCEPTING_ENTRIES;
> +}
> +
> +static void finish_parallel_checkout(void)
> +{
> +	if (parallel_checkout.status == PC_UNINITIALIZED)
> +		BUG("cannot finish parallel checkout: not initialized yet");
> +
> +	free(parallel_checkout.items);
> +	memset(&parallel_checkout, 0, sizeof(parallel_checkout));
> +}
> +
> +static int is_eligible_for_parallel_checkout(const struct cache_entry *ce,
> +					     const struct conv_attrs *ca)
> +{
> +	enum conv_attrs_classification c;
> +
> +	if (!S_ISREG(ce->ce_mode))
> +		return 0;
> +
> +	c = classify_conv_attrs(ca);
> +	switch (c) {
> +	case CA_CLASS_INCORE:
> +		return 1;
> +
> +	case CA_CLASS_INCORE_FILTER:
> +		/*
> +		 * It would be safe to allow concurrent instances of
> +		 * single-file smudge filters, like rot13, but we should not
> +		 * assume that all filters are parallel-process safe. So we
> +		 * don't allow this.
> +		 */
> +		return 0;
> +
> +	case CA_CLASS_INCORE_PROCESS:
> +		/*
> +		 * The parallel queue and the delayed queue are not compatible,
> +		 * so they must be kept completely separated. And we can't tell
> +		 * if a long-running process will delay its response without
> +		 * actually asking it to perform the filtering. Therefore, this
> +		 * type of filter is not allowed in parallel checkout.
> +		 *
> +		 * Furthermore, there should only be one instance of the
> +		 * long-running process filter as we don't know how it is
> +		 * managing its own concurrency. So, spreading the entries that
> +		 * requisite such a filter among the parallel workers would
> +		 * require a lot more inter-process communication. We would
> +		 * probably have to designate a single process to interact with
> +		 * the filter and send all the necessary data to it, for each
> +		 * entry.
> +		 */
> +		return 0;
> +
> +	case CA_CLASS_STREAMABLE:
> +		return 1;
> +
> +	default:
> +		BUG("unsupported conv_attrs classification '%d'", c);
> +	}
> +}

OK, the comments fairly clearly explain the reason for each case.
Good.

> +static int handle_results(struct checkout *state)
> +{
> +	int ret = 0;
> +	size_t i;
> +	int have_pending = 0;
> +
> +	/*
> +	 * We first update the successfully written entries with the collected
> +	 * stat() data, so that they can be found by mark_colliding_entries(),
> +	 * in the next loop, when necessary.
> +	 */
> +	for (i = 0; i < parallel_checkout.nr; ++i) {

We encourage post_increment++ when there is no particular reason to
do otherwise in this codebase (I won't repeat in the remainder of
this review).

> +static int reset_fd(int fd, const char *path)
> +{
> +	if (lseek(fd, 0, SEEK_SET) != 0)
> +		return error_errno("failed to rewind descriptor of %s", path);
> +	if (ftruncate(fd, 0))
> +		return error_errno("failed to truncate file %s", path);
> +	return 0;
> +}

This is in the error codepath when streaming fails, and we'll later
attempt the normal "read object in-core, write it out" codepath, but
is it enough to just ftruncate() it?  I am wondering why it is OK
not to unlink() the failed one---is it the caller who is responsible
for opening the file descriptor to write to, and at the layer of the
caller of this helper there is no way to re-open it, or something
like that?

	... /me looks ahead and it seems the answer is "yes".

> +static int write_pc_item_to_fd(struct parallel_checkout_item *pc_item, int fd,
> +			       const char *path)
> ...
> +	if (filter) {
> +		if (stream_blob_to_fd(fd, &pc_item->ce->oid, filter, 1)) {
> +			/* On error, reset fd to try writing without streaming */
> +			if (reset_fd(fd, path))
> +				return -1;
> +		} else {
> +			return 0;
> +		}
> +	}
> +
> +	new_blob = read_blob_entry(pc_item->ce, &size);
> ...
> +	wrote = write_in_full(fd, new_blob, size);

> +static int check_leading_dirs(const char *path, int len, int prefix_len)
> +{
> +	const char *slash = path + len;
> +
> +	while (slash > path && *slash != '/')
> +		slash--;

It is kind of surprising that we do not give us an easy-to-use
helper to find the separtor between dirname and basename.  If there
were, we do not even need this helper function with an unclear name
(i.e. "check" does not mean much to those who are trying to
understand the caller---"leading directories are checked for
what???" will be their question).

Perhaps create or find such a helper to remove this function and use
has_dirs_only_path() directly in the caller?

> +	return has_dirs_only_path(path, slash - path, prefix_len);
> +}

> +static void write_pc_item(struct parallel_checkout_item *pc_item,
> +			  struct checkout *state)
> +{
> +	unsigned int mode = (pc_item->ce->ce_mode & 0100) ? 0777 : 0666;
> +	int fd = -1, fstat_done = 0;
> +	struct strbuf path = STRBUF_INIT;
> +
> +	strbuf_add(&path, state->base_dir, state->base_dir_len);
> +	strbuf_add(&path, pc_item->ce->name, pc_item->ce->ce_namelen);
> +
> +	/*
> +	 * At this point, leading dirs should have already been created. But if
> +	 * a symlink being checked out has collided with one of the dirs, due to
> +	 * file system folding rules, it's possible that the dirs are no longer

Is "file system folding rule" clear to readers of the code after
this patch lands?  It isn't at least to me.

> +	 * present. So we have to check again, and report any path collisions.
> +	 */
> +	if (!check_leading_dirs(path.buf, path.len, state->base_dir_len)) {
> +		pc_item->status = PC_ITEM_COLLIDED;
> +		goto out;
> +	}

Thanks.

Matheus Tavares Nov. 3, 2020, 3:48 a.m. UTC | #2

On Mon, Nov 2, 2020 at 4:35 PM Junio C Hamano <[e-mail]> wrote:
>
> Matheus Tavares <[e-mail]> writes:
[...]
> >
> > @@ -536,6 +546,9 @@ int checkout_entry_ca(struct cache_entry *ce, struct conv_attrs *ca,
> >               ca = &ca_buf;
> >       }
> >
> > +     if (!enqueue_checkout(ce, ca))
> > +             return 0;
> > +
> >       return write_entry(ce, path.buf, ca, state, 0);
>
> It it is not wrong but feels strange that paths that cannot be
> handled by parallel codepath for whatever reason are written using
> the fallback code, but the fallback actually touches the disk before
> the queued paths for parallel writeout ;-)

Yeah... I also considered having a second "sequential_checkout_item"
queue, and iterating it after the parallel-eligible entries. But I
thought that it might be better to write the ineligible entries right
away and save a little memory (especially for the regular files, for
which we would also have to hold the conversion attributes).

With that said, I ended up adding a second queue in part 2, just for
symlinks. By postponing the checkout of symlinks we can avoid the
check_leading_dirs() function and the additional lstat() calls in the
workers. This also makes it possible to create the leading directories
in parallel (in part 3) with raceproof_create_file(), which is quite
nice as it only calls stat() when open() fails. And since symlinks
probably appear in smaller numbers than regular files, this second
queue should never get too long.

> What's the reason why
> some paths cannot be handled by the new codepath again?

Submodules and symlinks are not eligible for parallel checkout mainly
because it would be hard to detect collisions when they are involved.
For symlinks, one worker could create the symlink a/b => d right
before another worker tries to open() and write() a/b/c, which would
then produce the wrong a/d/c file. And for submodules, we could have a
worker checking out a submodule S while another worker writes the
colliding regular file s/f.

As for regular files, we don't parallelize the checkout of entries
which require external filters, mainly because we cannot guarantee
that such filters are parallel-process safe. But also, the
delayed-checkout queue is incompatible with the parallel-checkout
queue (in the sense that each entry should only be present in one of
the two queues).

> Also, can a
> path that is handled by the fallback code collide with other paths
> that are handled by the parallel codepath, and what happens for
> these paths?

Yes, it can happen. But the parallel-checkout machinery should be
ready for it. There are two cases:

1. Both paths collide in the basename (e.g. a/b and a/B)
2. One path collide in the dirname (e.g. a/b and a/B/c)

For both cases, the collision will happen when trying to write the
parallel-eligible path. This happens because, for now, all paths that
are ineligible for parallel-checkout are checked out first. So, in the
first case, we will detect the collision when open() fails in
write_pc_item().

The second case is a little trickier, since [in part 1] we create the
leading directories right before enqueueing an entry for
parallel-checkout. An ineligible entry could then collide with the
dirname of an already enqueued parallel-eligible entry, removing (and
replacing) the created dirs. Also, the ineligible entry could be a
symlink, and we want to avoid the case of workers writing the entry
a/b/c at a/d/c due to a symlink in b. These collisions with the
dirname are detected when has_dirs_only_path() fails in
check_leading_dirs().

Furthermore, there is no risk that has_dirs_only_path() succeeds, but
then another entry collides with the leading directories before the
actual checkout. Because, when we start the workers, no file or
directory is ever removed.

> >  }
> >
> > diff --git a/parallel-checkout.c b/parallel-checkout.c
> > new file mode 100644
> > index 0000000000..981dbe6ff3
> > --- /dev/null
> > +++ b/parallel-checkout.c
> > @@ -0,0 +1,368 @@
> > +#include "cache.h"
> > +#include "entry.h"
> > +#include "parallel-checkout.h"
> > +#include "streaming.h"
> > +
> > +enum pc_item_status {
> > +     PC_ITEM_PENDING = 0,
> > +     PC_ITEM_WRITTEN,
> > +     /*
> > +      * The entry could not be written because there was another file
> > +      * already present in its path or leading directories. Since
> > +      * checkout_entry_ca() removes such files from the working tree before
> > +      * enqueueing the entry for parallel checkout, it means that there was
> > +      * a path collision among the entries being written.
> > +      */
> > +     PC_ITEM_COLLIDED,
> > +     PC_ITEM_FAILED,
> > +};
> > +
> > +struct parallel_checkout_item {
> > +     /* pointer to a istate->cache[] entry. Not owned by us. */
> > +     struct cache_entry *ce;
> > +     struct conv_attrs ca;
> > +     struct stat st;
> > +     enum pc_item_status status;
> > +};
> > +
> > +struct parallel_checkout {
> > +     enum pc_status status;
> > +     struct parallel_checkout_item *items;
> > +     size_t nr, alloc;
> > +};
> > +
> > +static struct parallel_checkout parallel_checkout = { 0 };
>
> Can't we let this handled by BSS by not explicitly giving an initial
> value?

Good catch, thanks.

> > +enum pc_status parallel_checkout_status(void)
> > +{
> > +     return parallel_checkout.status;
> > +}
> > +
> > +void init_parallel_checkout(void)
> > +{
> > +     if (parallel_checkout.status != PC_UNINITIALIZED)
> > +             BUG("parallel checkout already initialized");
> > +
> > +     parallel_checkout.status = PC_ACCEPTING_ENTRIES;
> > +}
> > +
> > +static void finish_parallel_checkout(void)
> > +{
> > +     if (parallel_checkout.status == PC_UNINITIALIZED)
> > +             BUG("cannot finish parallel checkout: not initialized yet");
> > +
> > +     free(parallel_checkout.items);
> > +     memset(&parallel_checkout, 0, sizeof(parallel_checkout));
> > +}
> > +
> > +static int is_eligible_for_parallel_checkout(const struct cache_entry *ce,
> > +                                          const struct conv_attrs *ca)
> > +{
> > +     enum conv_attrs_classification c;
> > +
> > +     if (!S_ISREG(ce->ce_mode))
> > +             return 0;
> > +
> > +     c = classify_conv_attrs(ca);
> > +     switch (c) {
> > +     case CA_CLASS_INCORE:
> > +             return 1;
> > +
> > +     case CA_CLASS_INCORE_FILTER:
> > +             /*
> > +              * It would be safe to allow concurrent instances of
> > +              * single-file smudge filters, like rot13, but we should not
> > +              * assume that all filters are parallel-process safe. So we
> > +              * don't allow this.
> > +              */
> > +             return 0;
> > +
> > +     case CA_CLASS_INCORE_PROCESS:
> > +             /*
> > +              * The parallel queue and the delayed queue are not compatible,
> > +              * so they must be kept completely separated. And we can't tell
> > +              * if a long-running process will delay its response without
> > +              * actually asking it to perform the filtering. Therefore, this
> > +              * type of filter is not allowed in parallel checkout.
> > +              *
> > +              * Furthermore, there should only be one instance of the
> > +              * long-running process filter as we don't know how it is
> > +              * managing its own concurrency. So, spreading the entries that
> > +              * requisite such a filter among the parallel workers would
> > +              * require a lot more inter-process communication. We would
> > +              * probably have to designate a single process to interact with
> > +              * the filter and send all the necessary data to it, for each
> > +              * entry.
> > +              */
> > +             return 0;
> > +
> > +     case CA_CLASS_STREAMABLE:
> > +             return 1;
> > +
> > +     default:
> > +             BUG("unsupported conv_attrs classification '%d'", c);
> > +     }
> > +}
>
> OK, the comments fairly clearly explain the reason for each case.
> Good.
>
> > +static int handle_results(struct checkout *state)
> > +{
> > +     int ret = 0;
> > +     size_t i;
> > +     int have_pending = 0;
> > +
> > +     /*
> > +      * We first update the successfully written entries with the collected
> > +      * stat() data, so that they can be found by mark_colliding_entries(),
> > +      * in the next loop, when necessary.
> > +      */
> > +     for (i = 0; i < parallel_checkout.nr; ++i) {
>
> We encourage post_increment++ when there is no particular reason to
> do otherwise in this codebase (I won't repeat in the remainder of
> this review).

OK, I will fix the pre-increments, thanks.

> > +static int reset_fd(int fd, const char *path)
> > +{
> > +     if (lseek(fd, 0, SEEK_SET) != 0)
> > +             return error_errno("failed to rewind descriptor of %s", path);
> > +     if (ftruncate(fd, 0))
> > +             return error_errno("failed to truncate file %s", path);
> > +     return 0;
> > +}
>
> This is in the error codepath when streaming fails, and we'll later
> attempt the normal "read object in-core, write it out" codepath, but
> is it enough to just ftruncate() it?  I am wondering why it is OK
> not to unlink() the failed one---is it the caller who is responsible
> for opening the file descriptor to write to, and at the layer of the
> caller of this helper there is no way to re-open it, or something
> like that?

Right. We also avoid unlinking the failed one to keep the invariant
that the first worker to successfully open(O_CREAT | O_EXCL) a file
has the "ownership" for that path. So other workers that try to open
the same path will know that there is a collision and can immediately
abort checking out their entry.

>         ... /me looks ahead and it seems the answer is "yes".
>
> > +static int write_pc_item_to_fd(struct parallel_checkout_item *pc_item, int fd,
> > +                            const char *path)
> > ...
> > +     if (filter) {
> > +             if (stream_blob_to_fd(fd, &pc_item->ce->oid, filter, 1)) {
> > +                     /* On error, reset fd to try writing without streaming */
> > +                     if (reset_fd(fd, path))
> > +                             return -1;
> > +             } else {
> > +                     return 0;
> > +             }
> > +     }
> > +
> > +     new_blob = read_blob_entry(pc_item->ce, &size);
> > ...
> > +     wrote = write_in_full(fd, new_blob, size);
>
> > +static int check_leading_dirs(const char *path, int len, int prefix_len)
> > +{
> > +     const char *slash = path + len;
> > +
> > +     while (slash > path && *slash != '/')
> > +             slash--;
>
> It is kind of surprising that we do not give us an easy-to-use
> helper to find the separtor between dirname and basename.  If there
> were, we do not even need this helper function with an unclear name
> (i.e. "check" does not mean much to those who are trying to
> understand the caller---"leading directories are checked for
> what???" will be their question).
>
> Perhaps create or find such a helper to remove this function and use
> has_dirs_only_path() directly in the caller?

OK, I'll look into it. It would be better if we can reuse an already
present helper, since this call to has_dirs_only_path() will be
removed in part 2.

> > +     return has_dirs_only_path(path, slash - path, prefix_len);
> > +}
>
> > +static void write_pc_item(struct parallel_checkout_item *pc_item,
> > +                       struct checkout *state)
> > +{
> > +     unsigned int mode = (pc_item->ce->ce_mode & 0100) ? 0777 : 0666;
> > +     int fd = -1, fstat_done = 0;
> > +     struct strbuf path = STRBUF_INIT;
> > +
> > +     strbuf_add(&path, state->base_dir, state->base_dir_len);
> > +     strbuf_add(&path, pc_item->ce->name, pc_item->ce->ce_namelen);
> > +
> > +     /*
> > +      * At this point, leading dirs should have already been created. But if
> > +      * a symlink being checked out has collided with one of the dirs, due to
> > +      * file system folding rules, it's possible that the dirs are no longer
>
> Is "file system folding rule" clear to readers of the code after
> this patch lands?  It isn't at least to me.

OK, I will rephrase this paragraph to make it clearer.

Patch

diff --git a/Makefile b/Makefile
index 1fb0ec1705..10ee5e709b 100644
--- a/Makefile
+++ b/Makefile
@@ -945,6 +945,7 @@  LIB_OBJS += pack-revindex.o
 LIB_OBJS += pack-write.o
 LIB_OBJS += packfile.o
 LIB_OBJS += pager.o
+LIB_OBJS += parallel-checkout.o
 LIB_OBJS += parse-options-cb.o
 LIB_OBJS += parse-options.o
 LIB_OBJS += patch-delta.o
diff --git a/entry.c b/entry.c
index 9d79a5671f..6676954431 100644
--- a/entry.c
+++ b/entry.c
@@ -7,6 +7,7 @@ 
 #include "progress.h"
 #include "fsmonitor.h"
 #include "entry.h"
+#include "parallel-checkout.h"
 
 static void create_directories(const char *path, int path_len,
 			       const struct checkout *state)
@@ -426,8 +427,17 @@  static void mark_colliding_entries(const struct checkout *state,
 	for (i = 0; i < state->istate->cache_nr; i++) {
 		struct cache_entry *dup = state->istate->cache[i];
 
-		if (dup == ce)
-			break;
+		if (dup == ce) {
+			/*
+			 * Parallel checkout creates the files in no particular
+			 * order. So the other side of the collision may appear
+			 * after the given cache_entry in the array.
+			 */
+			if (parallel_checkout_status() == PC_RUNNING)
+				continue;
+			else
+				break;
+		}
 
 		if (dup->ce_flags & (CE_MATCHED | CE_VALID | CE_SKIP_WORKTREE))
 			continue;
@@ -536,6 +546,9 @@  int checkout_entry_ca(struct cache_entry *ce, struct conv_attrs *ca,
 		ca = &ca_buf;
 	}
 
+	if (!enqueue_checkout(ce, ca))
+		return 0;
+
 	return write_entry(ce, path.buf, ca, state, 0);
 }
 
diff --git a/parallel-checkout.c b/parallel-checkout.c
new file mode 100644
index 0000000000..981dbe6ff3
--- /dev/null
+++ b/parallel-checkout.c
@@ -0,0 +1,368 @@ 
+#include "cache.h"
+#include "entry.h"
+#include "parallel-checkout.h"
+#include "streaming.h"
+
+enum pc_item_status {
+	PC_ITEM_PENDING = 0,
+	PC_ITEM_WRITTEN,
+	/*
+	 * The entry could not be written because there was another file
+	 * already present in its path or leading directories. Since
+	 * checkout_entry_ca() removes such files from the working tree before
+	 * enqueueing the entry for parallel checkout, it means that there was
+	 * a path collision among the entries being written.
+	 */
+	PC_ITEM_COLLIDED,
+	PC_ITEM_FAILED,
+};
+
+struct parallel_checkout_item {
+	/* pointer to a istate->cache[] entry. Not owned by us. */
+	struct cache_entry *ce;
+	struct conv_attrs ca;
+	struct stat st;
+	enum pc_item_status status;
+};
+
+struct parallel_checkout {
+	enum pc_status status;
+	struct parallel_checkout_item *items;
+	size_t nr, alloc;
+};
+
+static struct parallel_checkout parallel_checkout = { 0 };
+
+enum pc_status parallel_checkout_status(void)
+{
+	return parallel_checkout.status;
+}
+
+void init_parallel_checkout(void)
+{
+	if (parallel_checkout.status != PC_UNINITIALIZED)
+		BUG("parallel checkout already initialized");
+
+	parallel_checkout.status = PC_ACCEPTING_ENTRIES;
+}
+
+static void finish_parallel_checkout(void)
+{
+	if (parallel_checkout.status == PC_UNINITIALIZED)
+		BUG("cannot finish parallel checkout: not initialized yet");
+
+	free(parallel_checkout.items);
+	memset(&parallel_checkout, 0, sizeof(parallel_checkout));
+}
+
+static int is_eligible_for_parallel_checkout(const struct cache_entry *ce,
+					     const struct conv_attrs *ca)
+{
+	enum conv_attrs_classification c;
+
+	if (!S_ISREG(ce->ce_mode))
+		return 0;
+
+	c = classify_conv_attrs(ca);
+	switch (c) {
+	case CA_CLASS_INCORE:
+		return 1;
+
+	case CA_CLASS_INCORE_FILTER:
+		/*
+		 * It would be safe to allow concurrent instances of
+		 * single-file smudge filters, like rot13, but we should not
+		 * assume that all filters are parallel-process safe. So we
+		 * don't allow this.
+		 */
+		return 0;
+
+	case CA_CLASS_INCORE_PROCESS:
+		/*
+		 * The parallel queue and the delayed queue are not compatible,
+		 * so they must be kept completely separated. And we can't tell
+		 * if a long-running process will delay its response without
+		 * actually asking it to perform the filtering. Therefore, this
+		 * type of filter is not allowed in parallel checkout.
+		 *
+		 * Furthermore, there should only be one instance of the
+		 * long-running process filter as we don't know how it is
+		 * managing its own concurrency. So, spreading the entries that
+		 * requisite such a filter among the parallel workers would
+		 * require a lot more inter-process communication. We would
+		 * probably have to designate a single process to interact with
+		 * the filter and send all the necessary data to it, for each
+		 * entry.
+		 */
+		return 0;
+
+	case CA_CLASS_STREAMABLE:
+		return 1;
+
+	default:
+		BUG("unsupported conv_attrs classification '%d'", c);
+	}
+}
+
+int enqueue_checkout(struct cache_entry *ce, struct conv_attrs *ca)
+{
+	struct parallel_checkout_item *pc_item;
+
+	if (parallel_checkout.status != PC_ACCEPTING_ENTRIES ||
+	    !is_eligible_for_parallel_checkout(ce, ca))
+		return -1;
+
+	ALLOC_GROW(parallel_checkout.items, parallel_checkout.nr + 1,
+		   parallel_checkout.alloc);
+
+	pc_item = &parallel_checkout.items[parallel_checkout.nr++];
+	pc_item->ce = ce;
+	memcpy(&pc_item->ca, ca, sizeof(pc_item->ca));
+	pc_item->status = PC_ITEM_PENDING;
+
+	return 0;
+}
+
+static int handle_results(struct checkout *state)
+{
+	int ret = 0;
+	size_t i;
+	int have_pending = 0;
+
+	/*
+	 * We first update the successfully written entries with the collected
+	 * stat() data, so that they can be found by mark_colliding_entries(),
+	 * in the next loop, when necessary.
+	 */
+	for (i = 0; i < parallel_checkout.nr; ++i) {
+		struct parallel_checkout_item *pc_item = &parallel_checkout.items[i];
+		if (pc_item->status == PC_ITEM_WRITTEN)
+			update_ce_after_write(state, pc_item->ce, &pc_item->st);
+	}
+
+	for (i = 0; i < parallel_checkout.nr; ++i) {
+		struct parallel_checkout_item *pc_item = &parallel_checkout.items[i];
+
+		switch(pc_item->status) {
+		case PC_ITEM_WRITTEN:
+			/* Already handled */
+			break;
+		case PC_ITEM_COLLIDED:
+			/*
+			 * The entry could not be checked out due to a path
+			 * collision with another entry. Since there can only
+			 * be one entry of each colliding group on the disk, we
+			 * could skip trying to check out this one and move on.
+			 * However, this would leave the unwritten entries with
+			 * null stat() fields on the index, which could
+			 * potentially slow down subsequent operations that
+			 * require refreshing it: git would not be able to
+			 * trust st_size and would have to go to the filesystem
+			 * to see if the contents match (see ie_modified()).
+			 *
+			 * Instead, let's pay the overhead only once, now, and
+			 * call checkout_entry_ca() again for this file, to
+			 * have it's stat() data stored in the index. This also
+			 * has the benefit of adding this entry and its
+			 * colliding pair to the collision report message.
+			 * Additionally, this overwriting behavior is consistent
+			 * with what the sequential checkout does, so it doesn't
+			 * add any extra overhead.
+			 */
+			ret |= checkout_entry_ca(pc_item->ce, &pc_item->ca,
+						 state, NULL, NULL);
+			break;
+		case PC_ITEM_PENDING:
+			have_pending = 1;
+			/* fall through */
+		case PC_ITEM_FAILED:
+			ret = -1;
+			break;
+		default:
+			BUG("unknown checkout item status in parallel checkout");
+		}
+	}
+
+	if (have_pending)
+		error(_("parallel checkout finished with pending entries"));
+
+	return ret;
+}
+
+static int reset_fd(int fd, const char *path)
+{
+	if (lseek(fd, 0, SEEK_SET) != 0)
+		return error_errno("failed to rewind descriptor of %s", path);
+	if (ftruncate(fd, 0))
+		return error_errno("failed to truncate file %s", path);
+	return 0;
+}
+
+static int write_pc_item_to_fd(struct parallel_checkout_item *pc_item, int fd,
+			       const char *path)
+{
+	int ret;
+	struct stream_filter *filter;
+	struct strbuf buf = STRBUF_INIT;
+	char *new_blob;
+	unsigned long size;
+	size_t newsize = 0;
+	ssize_t wrote;
+
+	/* Sanity check */
+	assert(is_eligible_for_parallel_checkout(pc_item->ce, &pc_item->ca));
+
+	filter = get_stream_filter_ca(&pc_item->ca, &pc_item->ce->oid);
+	if (filter) {
+		if (stream_blob_to_fd(fd, &pc_item->ce->oid, filter, 1)) {
+			/* On error, reset fd to try writing without streaming */
+			if (reset_fd(fd, path))
+				return -1;
+		} else {
+			return 0;
+		}
+	}
+
+	new_blob = read_blob_entry(pc_item->ce, &size);
+	if (!new_blob)
+		return error("unable to read sha1 file of %s (%s)", path,
+			     oid_to_hex(&pc_item->ce->oid));
+
+	/*
+	 * checkout metadata is used to give context for external process
+	 * filters. Files requiring such filters are not eligible for parallel
+	 * checkout, so pass NULL.
+	 */
+	ret = convert_to_working_tree_ca(&pc_item->ca, pc_item->ce->name,
+					 new_blob, size, &buf, NULL);
+
+	if (ret) {
+		free(new_blob);
+		new_blob = strbuf_detach(&buf, &newsize);
+		size = newsize;
+	}
+
+	wrote = write_in_full(fd, new_blob, size);
+	free(new_blob);
+	if (wrote < 0)
+		return error("unable to write file %s", path);
+
+	return 0;
+}
+
+static int close_and_clear(int *fd)
+{
+	int ret = 0;
+
+	if (*fd >= 0) {
+		ret = close(*fd);
+		*fd = -1;
+	}
+
+	return ret;
+}
+
+static int check_leading_dirs(const char *path, int len, int prefix_len)
+{
+	const char *slash = path + len;
+
+	while (slash > path && *slash != '/')
+		slash--;
+
+	return has_dirs_only_path(path, slash - path, prefix_len);
+}
+
+static void write_pc_item(struct parallel_checkout_item *pc_item,
+			  struct checkout *state)
+{
+	unsigned int mode = (pc_item->ce->ce_mode & 0100) ? 0777 : 0666;
+	int fd = -1, fstat_done = 0;
+	struct strbuf path = STRBUF_INIT;
+
+	strbuf_add(&path, state->base_dir, state->base_dir_len);
+	strbuf_add(&path, pc_item->ce->name, pc_item->ce->ce_namelen);
+
+	/*
+	 * At this point, leading dirs should have already been created. But if
+	 * a symlink being checked out has collided with one of the dirs, due to
+	 * file system folding rules, it's possible that the dirs are no longer
+	 * present. So we have to check again, and report any path collisions.
+	 */
+	if (!check_leading_dirs(path.buf, path.len, state->base_dir_len)) {
+		pc_item->status = PC_ITEM_COLLIDED;
+		goto out;
+	}
+
+	fd = open(path.buf, O_WRONLY | O_CREAT | O_EXCL, mode);
+
+	if (fd < 0) {
+		if (errno == EEXIST || errno == EISDIR) {
+			/*
+			 * Errors which probably represent a path collision.
+			 * Suppress the error message and mark the item to be
+			 * retried later, sequentially. ENOTDIR and ENOENT are
+			 * also interesting, but check_leading_dirs() should
+			 * have already caught these cases.
+			 */
+			pc_item->status = PC_ITEM_COLLIDED;
+		} else {
+			error_errno("failed to open file %s", path.buf);
+			pc_item->status = PC_ITEM_FAILED;
+		}
+		goto out;
+	}
+
+	if (write_pc_item_to_fd(pc_item, fd, path.buf)) {
+		/* Error was already reported. */
+		pc_item->status = PC_ITEM_FAILED;
+		goto out;
+	}
+
+	fstat_done = fstat_checkout_output(fd, state, &pc_item->st);
+
+	if (close_and_clear(&fd)) {
+		error_errno("unable to close file %s", path.buf);
+		pc_item->status = PC_ITEM_FAILED;
+		goto out;
+	}
+
+	if (state->refresh_cache && !fstat_done && lstat(path.buf, &pc_item->st) < 0) {
+		error_errno("unable to stat just-written file %s",  path.buf);
+		pc_item->status = PC_ITEM_FAILED;
+		goto out;
+	}
+
+	pc_item->status = PC_ITEM_WRITTEN;
+
+out:
+	/*
+	 * No need to check close() return. At this point, either fd is already
+	 * closed, or we are on an error path, that has already been reported.
+	 */
+	close_and_clear(&fd);
+	strbuf_release(&path);
+}
+
+static void write_items_sequentially(struct checkout *state)
+{
+	size_t i;
+
+	for (i = 0; i < parallel_checkout.nr; ++i)
+		write_pc_item(&parallel_checkout.items[i], state);
+}
+
+int run_parallel_checkout(struct checkout *state)
+{
+	int ret;
+
+	if (parallel_checkout.status != PC_ACCEPTING_ENTRIES)
+		BUG("cannot run parallel checkout: uninitialized or already running");
+
+	parallel_checkout.status = PC_RUNNING;
+
+	write_items_sequentially(state);
+	ret = handle_results(state);
+
+	finish_parallel_checkout();
+	return ret;
+}
diff --git a/parallel-checkout.h b/parallel-checkout.h
new file mode 100644
index 0000000000..e6d6fc01ea
--- /dev/null
+++ b/parallel-checkout.h
@@ -0,0 +1,27 @@ 
+#ifndef PARALLEL_CHECKOUT_H
+#define PARALLEL_CHECKOUT_H
+
+struct cache_entry;
+struct checkout;
+struct conv_attrs;
+
+enum pc_status {
+	PC_UNINITIALIZED = 0,
+	PC_ACCEPTING_ENTRIES,
+	PC_RUNNING,
+};
+
+enum pc_status parallel_checkout_status(void);
+void init_parallel_checkout(void);
+
+/*
+ * Return -1 if parallel checkout is currently not enabled or if the entry is
+ * not eligible for parallel checkout. Otherwise, enqueue the entry for later
+ * write and return 0.
+ */
+int enqueue_checkout(struct cache_entry *ce, struct conv_attrs *ca);
+
+/* Write all the queued entries, returning 0 on success.*/
+int run_parallel_checkout(struct checkout *state);
+
+#endif /* PARALLEL_CHECKOUT_H */
diff --git a/unpack-trees.c b/unpack-trees.c
index a511fadd89..1b1da7485a 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -17,6 +17,7 @@ 
 #include "object-store.h"
 #include "promisor-remote.h"
 #include "entry.h"
+#include "parallel-checkout.h"
 
 /*
  * Error messages expected by scripts out of plumbing commands such as
@@ -438,7 +439,6 @@  static int check_updates(struct unpack_trees_options *o,
 	if (should_update_submodules())
 		load_gitmodules_file(index, &state);
 
-	enable_delayed_checkout(&state);
 	if (has_promisor_remote()) {
 		/*
 		 * Prefetch the objects that are to be checked out in the loop
@@ -461,6 +461,9 @@  static int check_updates(struct unpack_trees_options *o,
 					   to_fetch.oid, to_fetch.nr);
 		oid_array_clear(&to_fetch);
 	}
+
+	enable_delayed_checkout(&state);
+	init_parallel_checkout();
 	for (i = 0; i < index->cache_nr; i++) {
 		struct cache_entry *ce = index->cache[i];
 
@@ -474,6 +477,7 @@  static int check_updates(struct unpack_trees_options *o,
 		}
 	}
 	stop_progress(&progress);
+	errs |= run_parallel_checkout(&state);
 	errs |= finish_delayed_checkout(&state, NULL);
 	git_attr_set_direction(GIT_ATTR_CHECKIN);