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

Re: [PATCH 1/5] unpack-trees: add basic support for parallel checkout

From
Christian Couder <christian.couder@gmail.com>
Date
Mar 31, 2021, 04:22 UTC
Message-ID
<CAP8UFD2eaaQEuytk6cPoYco2_dfdbsM3aAvJyYFqgYSfkZ487g@mail.gmail.com>
In-Reply-To
<a3383042e2ee6c454e024db7a9154dc979a5af9e.1616015337.git.matheus.bernardino@usp.br>

On Wed, Mar 17, 2021 at 10:12 PM Matheus Tavares <matheus.bernardino@usp.br> wrote:

Show 13 quoted lines
> +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;
> +};

It looks like this struct parallel_checkout contains what is called the parallel checkout queue in many places. It would be a bit better if a name or at least a comment could make that clear.

> +static struct parallel_checkout parallel_checkout;
[...]
Show 6 quoted lines
> +static void finish_parallel_checkout(void)
> +{
> +       if (parallel_checkout.status == PC_UNINITIALIZED)
> +               BUG("cannot finish parallel checkout: not initialized yet");
> +
> +       free(parallel_checkout.items);

Ok, it looks like the queue can indeed be freed like this as the items don't need their fields to be freed.

> +       memset(&parallel_checkout, 0, sizeof(parallel_checkout));
That should work to reset it.
Show 48 quoted lines
> +}
> +
> +static int is_eligible_for_parallel_checkout(const struct cache_entry *ce,
> +                                            const struct conv_attrs *ca)
> +{
> +       enum conv_attrs_classification c;
> +
> +       /*
> +        * Symlinks cannot be checked out in parallel as, in case of path
> +        * collision, they could racily replace leading directories of other
> +        * entries being checked out. Submodules are checked out in child
> +        * processes, which have their own parallel checkout queues.
> +        */
> +       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;

So it looks like we don't process entries that need filtering. It's a bit disappointing as the commit message says:

"This new interface allows us to enqueue some of the entries being checked out to later uncompress, smudge, and write them in parallel."

So it seems to say that entries could be smudged in parallel. Or maybe I am missing something?

Show 7 quoted lines
> +       case CA_CLASS_STREAMABLE:
> +               return 1;
> +
> +       default:
> +               BUG("unsupported conv_attrs classification '%d'", c);
> +       }
> +}
[...]
Show 40 quoted lines
> +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
s/it's/its/
Show 22 quoted lines
> +                        * 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"));

Is this an error that can actually happen? Or is it a bug? If this can actually happen what is the state of the working directory and what can the user do? Start another checkout with an option to do it sequentially?

> +       return ret;
> +}
[...]
Show 8 quoted lines
> +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;

I thought that we shouldn't use unsigned long anymore for sizes, but unfortunately it looks like that's what read_blob_entry() expects.

> +       size_t newsize = 0;

I don't think we need to initialize newsize. Also we could perhaps declare it closer to where it is used below.

Show 19 quoted lines
> +       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,

With the support of sha256, I guess we should avoid talking about sha1. Maybe: s/sha1/object/ Or maybe we could just say that we couldn't read the object, as read_blob_entry() would perhaps read it from a pack-file and not from a loose file?

Show 14 quoted lines
> +                            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;

"newsize" seems to be used only here. It would be nice if we could get rid of it and pass "&size" to strbuf_detach(), but maybe we cannot because of the unsigned long/size_t type mismatch. At least we could declare "newsize" in this scope though.

Show 10 quoted lines
> +       }
> +
> +       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 void write_pc_item(struct parallel_checkout_item *pc_item,
> +                         struct checkout *state)
> +{
> +       unsigned int mode = (pc_item->ce->ce_mode & 0100) ? 0777 : 0666;

It looks like we are using similar code in different places, so it's probably ok, but maybe it would be nice one day to use a macro or an inline function for this.

> +       int fd = -1, fstat_done = 0;
> +       struct strbuf path = STRBUF_INIT;
> +       const char *dir_sep;
Previous: Matheus TavaresNext: Matheus Tavares Bernardino
Message 3 of 40 in “Parallel Checkout (part 2)”
  1. 0/5 Parallel Checkout (part 2)Matheus Tavares, Mar 17, 2021
  2. 1/5 unpack-trees: add basic support for parallel checkoutMatheus Tavares, Mar 17, 2021
  3. Christian CouderMar 31, 2021
  4. Matheus Tavares BernardinoApr 2, 2021
  5. 3/5 parallel-checkout: add configuration optionsMatheus Tavares, Mar 17, 2021
  6. Christian CouderMar 31, 2021
  7. Matheus Tavares BernardinoApr 2, 2021
  8. 5/5 parallel-checkout: add design documentationMatheus Tavares, Mar 17, 2021
  9. Christian CouderMar 31, 2021
  10. 4/5 parallel-checkout: support progress displayingMatheus Tavares, Mar 17, 2021
  11. 2/5 parallel-checkout: make it truly parallelMatheus Tavares, Mar 17, 2021
  12. Christian CouderMar 31, 2021
  13. Matheus Tavares BernardinoApr 2, 2021
  14. Junio C HamanoMar 18, 2021
  15. Matheus TavaresMar 19, 2021
  16. Junio C HamanoMar 19, 2021
  17. Christian CouderMar 31, 2021
  18. 0/5 Parallel Checkout (part 2)Matheus Tavares, Apr 8, 2021
  19. 1/5 unpack-trees: add basic support for parallel checkoutMatheus Tavares, Apr 8, 2021
  20. 2/5 parallel-checkout: make it truly parallelMatheus Tavares, Apr 8, 2021
  21. 3/5 parallel-checkout: add configuration optionsMatheus Tavares, Apr 8, 2021
  22. 4/5 parallel-checkout: support progress displayingMatheus Tavares, Apr 8, 2021
  23. 5/5 parallel-checkout: add design documentationMatheus Tavares, Apr 8, 2021
  24. Junio C HamanoApr 8, 2021
  25. Junio C HamanoApr 16, 2021
  26. Matheus Tavares BernardinoApr 17, 2021
  27. Christian CouderApr 19, 2021
  28. 0/5 Parallel Checkout (part 2)Matheus Tavares, Apr 19, 2021
  29. 1/5 unpack-trees: add basic support for parallel checkoutMatheus Tavares, Apr 19, 2021
  30. 2/5 parallel-checkout: make it truly parallelMatheus Tavares, Apr 19, 2021
  31. 3/5 parallel-checkout: add configuration optionsMatheus Tavares, Apr 19, 2021
  32. 4/5 parallel-checkout: support progress displayingMatheus Tavares, Apr 19, 2021
  33. 5/5 parallel-checkout: add design documentationMatheus Tavares, Apr 19, 2021
  34. Christian CouderApr 19, 2021
  35. 0/5 Parallel Checkout (part 2)Matheus Tavares, Apr 19, 2021
  36. 1/5 unpack-trees: add basic support for parallel checkoutMatheus Tavares, Apr 19, 2021
  37. 2/5 parallel-checkout: make it truly parallelMatheus Tavares, Apr 19, 2021
  38. 3/5 parallel-checkout: add configuration optionsMatheus Tavares, Apr 19, 2021
  39. 4/5 parallel-checkout: support progress displayingMatheus Tavares, Apr 19, 2021
  40. 5/5 parallel-checkout: add design documentationMatheus Tavares, Apr 19, 2021

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.