| Message ID | bc8447cd9c106055a715305ab506adc6abae7713.1604521275.git.matheus.bernardino@usp.br (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Parallel Checkout (part I) | expand |
On Wed, Nov 4, 2020 at 9:34 PM Matheus Tavares <matheus.bernardino@usp.br> wrote: > > 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. I would think that it might be more logical to first add a configuration that does nothing, then add writing the queued entries in sequence without parallelism, and then add actual parallelism. > 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. Is this needed in this step that only writes the queued entries in sequence without parallelism, or could this be added later, before the step that adds actual parallelism? > 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). So I guess that PC_ITEM_COLLIDED will then be used to decide which entries will not be checked out in parallel? > I also experimented with the idea of not overwriting colliding entries, > and it seemed to work well in my simple tests. There are a number of co-author of this patch, so it's not very clear who "I" is. Maybe: "The idea of not overwriting colliding entries seemed to work well in simple tests, however ..." > 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. Ok. > 5 files changed, 410 insertions(+), 3 deletions(-) It looks like a lot of new code in one patch/commit, which is why it might be interesting to split it. > @@ -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. > + */ Is it really the case right now that the code creates files in no particular order or will that be the case later when actual parallelism is implemented? > + if (parallel_checkout_status() == PC_RUNNING) > + continue; > + else > + break; > + } > +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; > +}; "item" seems not very clear to me. If there is only one parallel_checkout_item for each cache_entry then it might be better to use "parallel_checkout_entry" instead of "parallel_checkout_item". > +enum pc_status { > + PC_UNINITIALIZED = 0, > + PC_ACCEPTING_ENTRIES, > + PC_RUNNING, > +}; > + > +enum pc_status parallel_checkout_status(void); > +void init_parallel_checkout(void); Maybe a comment to tell what the above function does could be helpful. If I had to guess, I would write something like: /* * Put parallel checkout into the PC_ACCEPTING_ENTRIES state. * Should be used only when in the PC_UNINITIALIZED state. */ > +/* > + * Return -1 if parallel checkout is currently not enabled Is it "enabled" or "initialized" or "configured" here? Does it refer to `enum pc_status` or a config option or something else? Looking at the code, it is testing if the status PC_ACCEPTING_ENTRIES, so perhaps: s/not enabled/not accepting entries/ > 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);
Hi, Christian On Sun, Dec 6, 2020 at 8:36 AM Christian Couder <christian.couder@gmail.com> wrote: > > On Wed, Nov 4, 2020 at 9:34 PM Matheus Tavares > <matheus.bernardino@usp.br> wrote: > > > > 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. I just noticed that this part of the commit message is a little outdated. I'll fix it for v5. Currently, the parallelism and configuration are added in the same patch (the next one). This way, the patch that adds parallelism can already include runtime numbers for different configuration values (which shows when the change is beneficial). > I would think that it might be more logical to first add a > configuration that does nothing, then add writing the queued entries > in sequence without parallelism, and then add actual parallelism. I'm not sure I get the idea. Would the first patch add just the documentation for `checkout.workers` and `checkout.thresholdForParallelism` in `Documentation/config/checkout.txt`, without the support for it in the code? In that case, wouldn't the patch become somewhat incomplete on its own? > > 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. > > Is this needed in this step that only writes the queued entries in > sequence without parallelism, or could this be added later, before the > step that adds actual parallelism? This is already used in this patch. Even though the parallel checkout machinery only learns to spawn additional workers in the next patch, it can already encounter path collisions when writing the entries sequentially. PC_ITEM_COLLIDED is then used to mark the colliding entries, so that they can be properly handled later. > > 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). > > So I guess that PC_ITEM_COLLIDED will then be used to decide which > entries will not be checked out in parallel? Yes, in the next patch, the parallel workers will detect collisions when `open(path, O_CREAT | O_EXCL)` fails with EEXIST or EISDIR. The workers then mark such items with PC_ITEM_COLLIDED and let the main process sequentially write them later. > > I also experimented with the idea of not overwriting colliding entries, > > and it seemed to work well in my simple tests. > > There are a number of co-author of this patch, so it's not very clear > who "I" is. Maybe: > > "The idea of not overwriting colliding entries seemed to work well in > simple tests, however ..." Makes sense, thanks. > > 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. > > Ok. > > > 5 files changed, 410 insertions(+), 3 deletions(-) > > It looks like a lot of new code in one patch/commit, which is why it > might be interesting to split it. Yeah, this and the following patch ended up quite big... But I wasn't sure how to further split them while still keeping each part buildable and self-contained :( > > @@ -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. > > + */ > > Is it really the case right now that the code creates files in no > particular order or will that be the case later when actual > parallelism is implemented? In this patch, the code already creates files in no particular order. Since not all entries are eligible for parallel checkout, and because ineligible entries are written first, the files are not created in the same order that they appear in istate->cache[]. (Even though everything is still written sequentially in this patch). > > + if (parallel_checkout_status() == PC_RUNNING) > > + continue; > > + else > > + break; > > + } > > > +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; > > +}; > > "item" seems not very clear to me. If there is only one > parallel_checkout_item for each cache_entry then it might be better to > use "parallel_checkout_entry" instead of "parallel_checkout_item". Hmm, I'm a little uncertain about this one. I usually use "item" and "entry" interchangeably when talking about elements on a list, as in this case. Could perhaps the 'struct parallel_checkout_item' definition be unclear because it's far from the 'struct parallel_checkout', where the list is actually defined? > > +enum pc_status { > > + PC_UNINITIALIZED = 0, > > + PC_ACCEPTING_ENTRIES, > > + PC_RUNNING, > > +}; > > + > > +enum pc_status parallel_checkout_status(void); > > +void init_parallel_checkout(void); > > Maybe a comment to tell what the above function does could be helpful. > If I had to guess, I would write something like: > > /* > * Put parallel checkout into the PC_ACCEPTING_ENTRIES state. > * Should be used only when in the PC_UNINITIALIZED state. > */ OK, will do, thanks! > > +/* > > + * Return -1 if parallel checkout is currently not enabled > > Is it "enabled" or "initialized" or "configured" here? Does it refer > to `enum pc_status` or a config option or something else? Looking at > the code, it is testing if the status PC_ACCEPTING_ENTRIES, so > perhaps: s/not enabled/not accepting entries/ Yes, that's better, thanks!
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..fd871b09d3 --- /dev/null +++ b/parallel-checkout.c @@ -0,0 +1,362 @@ +#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; + +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(¶llel_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 = ¶llel_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 = ¶llel_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 = ¶llel_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 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; + const char *dir_sep; + + strbuf_add(&path, state->base_dir, state->base_dir_len); + strbuf_add(&path, pc_item->ce->name, pc_item->ce->ce_namelen); + + dir_sep = find_last_dir_sep(path.buf); + + /* + * The leading dirs should have been already created by now. But, in + * case of path collisions, one of the dirs could have been replaced by + * a symlink (checked out after we enqueued this entry for parallel + * checkout). Thus, we must check the leading dirs again. + */ + if (dir_sep && !has_dirs_only_path(path.buf, dir_sep - path.buf, + 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 the above has_dirs_only_path() + * call 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(¶llel_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);
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 <pclouds@gmail.com> Co-authored-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br> --- Makefile | 1 + entry.c | 17 ++- parallel-checkout.c | 362 ++++++++++++++++++++++++++++++++++++++++++++ parallel-checkout.h | 27 ++++ unpack-trees.c | 6 +- 5 files changed, 410 insertions(+), 3 deletions(-) create mode 100644 parallel-checkout.c create mode 100644 parallel-checkout.h