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

2015-04-22 Thread Jeff King
On Wed, Apr 22, 2015 at 12:14:08PM -0700, Stefan Beller wrote: > > FWIW, we already use a magic value of "25 extra" in open_packed_git_1. I > > don't know if that means the number has been proven in practice, or if > > it is simply that nobody actually exercises the pack_max_fds code. I > > suspec

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

2015-04-22 Thread Stefan Beller
On Tue, Apr 21, 2015 at 4:21 PM, Jeff King wrote: > On Mon, Apr 20, 2015 at 05:31:11PM -0700, Stefan Beller wrote: > >> When running the test locally, i.e. not in the test suite, but typing >> the commands >> myself into the shell, Git is fine with having just 5 file descriptors left. >> The addit

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

2015-04-21 Thread Jeff King
On Mon, Apr 20, 2015 at 05:31:11PM -0700, Stefan Beller wrote: > When running the test locally, i.e. not in the test suite, but typing > the commands > myself into the shell, Git is fine with having just 5 file descriptors left. > The additional 4 required fds come from beign run inside the test s

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

2015-04-21 Thread Stefan Beller
On Tue, Apr 21, 2015 at 10:19 AM, Junio C Hamano wrote: > Stefan Beller writes: > >> On Mon, Apr 20, 2015 at 3:51 PM, Junio C Hamano wrote: >> >>> On the core management side, xmalloc() and friends retry upon >>> failure, after attempting to free the resource. I wonder if your >>> codepath can

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

2015-04-21 Thread Junio C Hamano
Stefan Beller writes: > On Mon, Apr 20, 2015 at 3:51 PM, Junio C Hamano wrote: > >> On the core management side, xmalloc() and friends retry upon >> failure, after attempting to free the resource. I wonder if your >> codepath can do something similar to that, perhaps? > > But then we'd need to

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

2015-04-21 Thread Michael Haggerty
On 04/21/2015 12:51 AM, Junio C Hamano wrote: > Stefan Beller writes: > >> 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

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

2015-04-20 Thread Stefan Beller
On Mon, Apr 20, 2015 at 4:07 PM, Stefan Beller wrote: > On Mon, Apr 20, 2015 at 3:51 PM, Junio C Hamano wrote: >> Stefan Beller writes: >> >>> 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, >>

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

2015-04-20 Thread Stefan Beller
On Mon, Apr 20, 2015 at 3:51 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> 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 apparentl

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

2015-04-20 Thread Junio C Hamano
Stefan Beller writes: > 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 sta

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

2015-04-20 Thread Stefan Beller
On Fri, Apr 17, 2015 at 4:31 PM, Stefan Beller wrote: > On Fri, Apr 17, 2015 at 3:17 PM, Stefan Beller wrote: >> On Fri, Apr 17, 2015 at 3:12 PM, Junio C Hamano 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 'n

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

2015-04-17 Thread Stefan Beller
On Fri, Apr 17, 2015 at 3:17 PM, Stefan Beller wrote: > On Fri, Apr 17, 2015 at 3:12 PM, Junio C Hamano 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,

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

2015-04-17 Thread Stefan Beller
On Fri, Apr 17, 2015 at 3:12 PM, Junio C Hamano 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. -- To unsubscribe from this list: send the

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

2015-04-17 Thread Junio C Hamano
Junio C Hamano writes: > Stefan Beller writes: > >> * 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-l

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

2015-04-17 Thread Junio C Hamano
Stefan Beller writes: > * 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 ther