# Re: Multi-threaded 'git clone' 3 messages from 2015-02-17 to 2015-02-18. Participants: Martin Fick, Junio C Hamano. Thread: https://gitlist.dev/t/38578 ## Martin Fick, 2015-02-17 05:20 Subject: Re: Multi-threaded 'git clone' Message-ID: <20150217052007.CC8B713FECF@smtp.codeaurora.org> URL: https://gitlist.dev/e/20150217052007.CC8B713FECF%40smtp.codeaurora.org ``` There currently is a thread on the Gerrit list about how much faster cloning can be when using Gerrit/jgit GCed packs with bitmaps versus C git GCed packs with bitmaps. Some differences outlined are that jgit seems to have more bitmaps, it creates one for every refs/heads, is C git doing that? Another difference seems to be that jgit creates two packs, splitting stuff not reachable from refs/heads into its own pack. This makes a clone have zero CPU server side in the pristine case. In the Gerrit use case, this second "unreachable" packfile can be sizeable, I wonder if there are other use cases where this might also be the case (and this slowing down clones for C git GCed repos)? If there is not a lot of parallelism left to squeak out, perhaps a focus with better returns is trying to do whatever is possible to make all clones (and potentially any fetch use case deemed important on a particular server) have zero CPU? Depending on what a server's primary mission is, I could envision certain admins willing to sacrifice significant amounts of disk space to speed up their fetches. Perhaps some more extreme thinking (such as what must have led to bitmaps) is worth brainstorming about to improve server use cases? What if an admin were willing to sacrifice a packfile for every use case he deemed important, could git be made to support that easily? For example, maybe the admin considers a clone or a fetch from master to be important, could zero percent CPU be achieved regularly for those two use cases? Cloning is possible if the repository were repacked in the jgit style after any push to a head. Is it worth exploring ways of making GC efficient enough to make this feasible? Can bitmaps be leveraged to make repacking faster? I believe that at least reachability checking could potentially be improved with bitmaps? Are there potentially any ways to make better deltification reuse during repacking (not bitmap related), by somehow reversing or translating deltas to new objects that were just received, without actually recalculating them, but yet still getting most objects deltified against the newest objects (achieving the same packs as git GC would achieve today, but faster)? What other pieces need to be improved to make repacking faster? As for the single branch fetch case, could this somehow be improved by allocating one or more packfiles to this use case? The simplest single branch fetch use case is likely someone doing a git init followed by a single branch fetch. I think the android repo tool can be used in this way, so this may actually be a common use case? With a packfile dedicated to this branch, git should be able to just stream it out without any CPU. But I think git would need to know this packfile exists to be able to use it. It would be nice if bitmaps could help here, but I believe bitmaps can so far only be used for one packfile. I understand that making bitmaps span multiple packfiles would be very complicated, but maybe it would not be so hard to support bitmaps on multiple packfiles if each of these were "self contained"? By self contained I mean that all objects referenced by objects in the packfile were contained in that packfile. What other still unimplemented caching techniques could be used to improve clone/fetch use cases? - Shallow clones (dedicate a special packfile to this, what about another bitmap format that only maps objects in a single tree to help this)? - Small fetches (simple branch FF updates), I suspect these are fast enough, but if not, maybe caching some thin packs (that could result in zero CPU requests for many clients) would be useful? Maybe spread these out exponentially over time so that many will be available for recent updates and fewer for older updates? I know git normally throws away thin packs after receiving them and resolving them, but if it kept them around (maybe in a special directory), it seems that they could be useful for updating other clients with zero CPU? A thin pack cache might be something really easy to manage based on file timestamps, an admin may simply need to set a max cache size. But how can git know what thin packs it has, and what they would be useful for, name them with their start and ending shas? Sorry for the long winded rant. I suspect that some variation of all my suggestions have already been suggested, but maybe they will rekindle some older, now useful thoughts, or inspire some new ones. And maybe some of these are better to pursue then more parallelism? -Martin Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative ProjectOn Feb 16, 2015 8:47 AM, Jeff King wrote: > > On Mon, Feb 16, 2015 at 07:31:33AM -0800, David Lang wrote: > > > >Then the server streams the data to the client. It might do some light > > >work transforming the data as it comes off the disk, but most of it is > > >just blitted straight from disk, and the network is the bottleneck. > > > > Depending on how close to full the WAN link is, it may be possible to > > improve this with multiple connections (again, referencing bbcp), but > > there's also the question of if it's worth trying to use the entire WAN for > > a single user. The vast majority of the time the server is doing more than > > one thing and would rather let any individual user wait a bit and service > > the other users. > > Yeah, I have seen clients that make multiple TCP connections to each > request a chunk of a file in parallel. The short answer is that this is > going to be very hard with git. Each clone generates the pack on the fly > based on what's on disk and streams it out. It should _usually_ be the > same, but there's nothing to guarantee byte-for-byte equality between > invocations. So you'd have to multiplex all of the connections into the > same server process. And even then it's hard; that process knows its > going to send you byte the bytes for object X, but it doesn't know at > exactly which offset until it gets there, which makes sending things out > of order tricky. And the whole output is checksummed by a single sha1 > over the whole stream that comes at the end. > > I think the most feasible thing would be to quickly spool it to a server > on the LAN, and then use an existing fetch-in-parallel tool to grab it > from there over the WAN. > > -Peff > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at  http://vger.kernel.org/majordomo-info.html ``` ## Junio C Hamano, 2015-02-17 23:32 Subject: Re: Multi-threaded 'git clone' Message-ID: URL: https://gitlist.dev/e/xmqqegpoxgf3.fsf%40gitster.dls.corp.google.com In-Reply-To: <20150217052007.CC8B713FECF@smtp.codeaurora.org> ``` Martin Fick writes: > Sorry for the long winded rant. I suspect that some variation of all > my suggestions have already been suggested, but maybe they will > rekindle some older, now useful thoughts, or inspire some new ones. > And maybe some of these are better to pursue then more parallelism? We avoid doing a grand design document without having some prototype implementation, but I think the limitation of the current protocol has become apparent enough that we should do something about it, and we should do it in a way that different implementations of Git can all implement. I think "multi-threaded clone" is a wrong title for this discussion, in that the user does not care if it is done by multi-threading the current logic or in any other way. The user just wants a faster clone. In addition, the current "fetch" protocol has the following problems that limit us: - It is not easy to make it resumable, because we recompute every time. This is especially problematic for the initial fetch aka "clone" as we will be talking about a large transfer [*1*]. - The protocol extension has a fairly low length limit [*2*]. - Because the protocol exchange starts by the server side advertising all its refs, even when the fetcher is interested in a single ref, the initial overhead is nontrivial, especially when you are doing a small incremental update. The worst case is an auto-builder that polls every five minutes, even when there is no new commits to be fetched [*3*]. - Because we recompute every time, taking into account of what the fetcher has, in addition to what the fetcher obtained earlier from us in order to reduce the transferred bytes, the payload for incremental updates become tailor-made for each fetch and cannot be easily reused [*4*]. I'd like to see a new protocol that lets us overcome the above limitations (did I miss others? I am sure people can help here) sometime this year. [Footnotes] *1* The "first fetch this bundle from elsewhere and then come back here for incremental updates" raised earlier in this thread may be a way to alleviate this, as the large bundle can be served from a static file. *2* An earlier "this symbolic ref points at that concrete ref" attempt failed because of this and we only talk about HEAD. *3* A new "fetch" protocol must avoid this "one side blindly gives a large message as the first thing". I have been toying with the idea of making the fetcher talk first, by declaring "I am interested in your refs that match refs/heads/* or refs/tags/*, and I have a superset of objects that are reachable from the set of refs' values X you gave me earlier", where X is a small token generated by hashing the output from "git ls-remote $there refs/heads/* refs/tags/*". In the best case where the server understands what X is and has a cached pack data, it can then send: - differences in the refs that match the wildcards (e.g. "Back then at X I did not have refs/heads/next but now I do and it points at this commit. My refs/heads/master is now at that commit. I no longer have refs/heads/pu. Everything else in the refs/ hierarchy you are interested in is the same as state X"). - The new name of the state Y (again, the hashed value of the output from "git ls-remote $there refs/heads/* refs/tags/*") to make sure the above differences can be verified at the receiving end. - the cached pack data that contains all necessary objects between X and Y. Note that the above would work if and only if we accept that it is OK to send objects between the remote tracking branches the fetcher has (i.e. the objects it last fetched from the server) and the current tips of branches the server has, without optimizing by taking into account that some commits in that set may have already been obtained by the fetcher from a third-party. If the server does not recognize state X (after all it is just a SHA-1 hash value, so the server cannot recreate the set of refs and their values from it unless it remembers), the exchange would have to degenerate to the traditional transfer. The server would want to recognize the result of hashing an empty string, though. The fetcher is saying "I have nothing" in that case. *4* The scheme in *3* can be extended to bring the fetcher step-wise. If the server's state was X when the fetcher last contacted it, and since then the server received multiple pushes and has two snapshots of states, Y and Z, then the exchange may go like this: fetcher: I am interested in refs/heads/* and refs/tags/* and I have your state X. server: Here is the incremental difference to the refs and the end result should hash to Y. Here comes the pack data to bring you up to date. fetcher: (after receiving, unpacking and updating the remote-tracking refs) Thanks. Do you have more? server: Yes, here is the incremental difference to the refs and the end result should hash to Z. Here comes the pack data to bring you up to date. fetcher: (after receiving, unpacking and updating the remote-tracking refs) Thanks. Do you have more? server: No, you are now fully up to date with me. Bye. ``` ## Junio C Hamano, 2015-02-18 03:14 Subject: Re: Multi-threaded 'git clone' Message-ID: URL: https://gitlist.dev/e/CAPc5daWK-GbjL%3DYEyW55bcBELoq05dy4umh11upG%3DYxKQuFMpQ%40mail.gmail.com In-Reply-To: ``` On Tue, Feb 17, 2015 at 3:32 PM, Junio C Hamano wrote: A few typofixes and clarifications. > *4* The scheme in *3* can be extended to bring the fetcher > step-wise. If the server's state was X when the fetcher last "bring the fetcher up-to-date step-wise", or "update the fetcher step-wise". > contacted it, and since then the server received multiple pushes > and has two snapshots of states, Y and Z, then the exchange may > go like this: > > fetcher: I am interested in refs/heads/* and refs/tags/* and I > have your state X. > > server: Here is the incremental difference to the refs and the > end result should hash to Y. Here comes the pack data > to bring you up to date. > > fetcher: (after receiving, unpacking and updating the > remote-tracking refs) Thanks. Do you have more? > > server: Yes, here is the incremental difference to the refs and the > end result should hash to Z. Here comes the pack data > to bring you up to date. > > fetcher: (after receiving, unpacking and updating the > remote-tracking refs) Thanks. Do you have more? > > server: No, you are now fully up to date with me. Bye. The initial part of this exchange may go like this, if the state the fetcher grabbed the last time from this server is even older than X: fetcher: I am interested in refs/heads/* and refs/tags/* and I have your state W (or "I know I am too old that I do not know what you call that state"). server: Sorry, I do not know what W is. Please be more specific. fetcher: Here are the refs and their objects: refs/heads/master points at commit A, refs/heads/maint points at commit B, ... server: (goes and checks and finds out that fetcher is behind X). OK, I'll compute a custom pack to bring you up to date with one of my states. Here is the incremental difference to the refs, and the end result should hash to X. Here comes the pack data. fetcher: (after receiving, unpacking and updating the remote-tracking refs) Thanks. Do you have more? After that, the server would update this client to state Y and then state Z as above. Needless to say, this would naturally extend to a case where you follow only a single branch (you would say "I am interested in your refs/heads/dev" with a wildcard that matches exactly that branch). Of course, depending on the access pattern by common project participants, the server side may choose what set of refs to prepare such snapshots and uncommon requests may always be served by the traditional object enumeration codepath. ```