Re: [PATCH 0/3] Another approach to large transactions

4 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: [PATCH 0/3] Another approach to large transactions

From: Junio C Hamano <hidden>
Date: 2016-06-15 23:04:28

Junio C Hamano [off-list ref] writes:
Stefan Beller [off-list ref] writes:
quoted
* We keep the speed on small transactions 
  (no close and reopen of fds in small transactions)

* No refactoring for refs included, only minimally invasive to the refs.c code

* applies on top of origin/sb/remove-fd-from-ref-lock replacing the last
  commit there (I reworded the commit message of the last patch of that tip,
  being the first patch in this series)
  
* another approach would be to move the fd counting into the lock file api,
  I think that's not worth it for now.
I agree that it is a good direction to go to limit the number of
open file descriptors.  Overall it looked good to me.
This is now pushed out and sitting at the tip of 'pu'.  It seems to
break one of the tests in 1400 when merged to 'next', but I didn't
look it closely.

Thanks.

Re: [PATCH 0/3] Another approach to large transactions

From: Stefan Beller <hidden>
Date: 2016-06-15 23:04:28

On Fri, Apr 17, 2015 at 3:12 PM, Junio C Hamano [off-list ref] wrote:
This is now pushed out and sitting at the tip of 'pu'.  It seems to
break one of the tests in 1400 when merged to 'next', but I didn't
look it closely.

Thanks.
ok, I'll look more closely.

Re: [PATCH 0/3] Another approach to large transactions

From: Stefan Beller <hidden>
Date: 2016-06-15 23:04:28

On Fri, Apr 17, 2015 at 3:17 PM, Stefan Beller [off-list ref] wrote:
On Fri, Apr 17, 2015 at 3:12 PM, Junio C Hamano [off-list ref] wrote:
quoted
This is now pushed out and sitting at the tip of 'pu'.  It seems to
break one of the tests in 1400 when merged to 'next', but I didn't
look it closely.

Thanks.
ok, I'll look more closely.
Apparently I screwed up even before sending the patches over the wire.

  not ok 144 - large transaction deleting branches does not burst open
file limit

fails in my local branch as well as origin/pu as well on
origin/sb/remove-fd-from-ref-lock

So there is a pretty strong argument, the code is only improving
large transaction creating branches and not deleting branches.

Re: [PATCH 0/3] Another approach to large transactions

From: Stefan Beller <hidden>
Date: 2016-06-15 23:04:29

On Fri, Apr 17, 2015 at 4:31 PM, Stefan Beller [off-list ref] wrote:
On Fri, Apr 17, 2015 at 3:17 PM, Stefan Beller [off-list ref] wrote:
quoted
On Fri, Apr 17, 2015 at 3:12 PM, Junio C Hamano [off-list ref] wrote:
quoted
This is now pushed out and sitting at the tip of 'pu'.  It seems to
break one of the tests in 1400 when merged to 'next', but I didn't
look it closely.

Thanks.
ok, I'll look more closely.
Apparently I screwed up even before sending the patches over the wire.
For the deleting refs test failing:
The problem comes from guessing the number of fds we're allowed to use.
At first I thought it was a fundamental issue with the code being broken, but
it turns out we just need a larger offset as we apparently have 9 files open
already, before the transaction even starts.
I did not expect the number to be that high, which is why I came up with the
arbitrary number of 8 (3 for stdin/out/err, maybe packed refs and reflog so I
guessed, 8 would do fine).

I am not sure if the 9 is a constant or if it scales to some unknown
property yet.
So to make the series work, all we need is:

- int remaining_fds = get_max_fd_limit() - 8;
+ int remaining_fds = get_max_fd_limit() - 9;

I am going to try to understand where the 9 comes from and resend the patches.

Thanks,
Stefan
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help