Re: [PATCH v2] pack-objects: fix performance issues on packing large deltas
- From
Duy Nguyen <pclouds@gmail.com>
- Date
- Jul 23, 2018, 18:38 UTC
- Message-ID
- <CACsJy8BskYdANe9HnuLj8sqa8hRqzSAQ+q11C8faJ-YBtA3Xeg@mail.gmail.com>
- In-Reply-To
- <xmqq8t617rqv.fsf@gitster-ct.c.googlers.com>
On Mon, Jul 23, 2018 at 8:04 PM Junio C Hamano <gitster@pobox.com> wrote:
Show 10 quoted lines
> > Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes: > > > Access to e->delta_size_ (and by extension > > pack->delta_size[e - pack->objects]) is unprotected as before, the > > thread scheduler in pack-objects must make sure "e" is never updated > > by two different threads. > > OK. Do we need to worry about "e" (e.g. "e->delta_size_valid") > being accessed while/before it is set by another thread?
I left some details out because I think it's getting to a gray area. We already do this
if (!DELTA(trg_entry)) {
max_size = trg_size/2 - the_hash_algo->rawsz;
ref_depth = 1;
} else {
max_size = DELTA_SIZE(trg_entry);
...
SET_DELTA(trg_entry, src_entry);
SET_DELTA_SIZE(trg_entry, delta_size);if the bottom half is running on one thread and stopped in the middle while the top half is running in another thread, we have a problem. But perhaps max_size is not that big a deal because incorrect max_size may produce a bad pack but can't corrupt it.
I will have to study the thread dispatch code more to have a better answer, unfortunately. -- Duy