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 p...@peff.net 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

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 suspect it is

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 gits...@pobox.com wrote: Stefan Beller sbel...@google.com writes: On Mon, Apr 20, 2015 at 3:51 PM, Junio C Hamano gits...@pobox.com wrote: On the core management side, xmalloc() and friends retry upon failure, after attempting to free the

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

2015-04-21 Thread Junio C Hamano
Stefan Beller sbel...@google.com writes: On Mon, Apr 20, 2015 at 3:51 PM, Junio C Hamano gits...@pobox.com 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,

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 sbel...@google.com 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

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

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

2015-04-20 Thread Junio C Hamano
Stefan Beller sbel...@google.com 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

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 gits...@pobox.com wrote: Stefan Beller sbel...@google.com 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

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 sbel...@google.com wrote: On Mon, Apr 20, 2015 at 3:51 PM, Junio C Hamano gits...@pobox.com wrote: Stefan Beller sbel...@google.com writes: The problem comes from guessing the number of fds we're allowed to use. At first I thought it was a

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 sbel...@google.com wrote: On Fri, Apr 17, 2015 at 3:17 PM, Stefan Beller sbel...@google.com wrote: On Fri, Apr 17, 2015 at 3:12 PM, Junio C Hamano gits...@pobox.com wrote: This is now pushed out and sitting at the tip of 'pu'. It seems to break

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

2015-04-17 Thread Junio C Hamano
Stefan Beller sbel...@google.com 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

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 gits...@pobox.com 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

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 sbel...@google.com wrote: On Fri, Apr 17, 2015 at 3:12 PM, Junio C Hamano gits...@pobox.com 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

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

2015-04-17 Thread Junio C Hamano
Junio C Hamano gits...@pobox.com writes: Stefan Beller sbel...@google.com 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

[PATCH 0/3] Another approach to large transactions

2015-04-16 Thread Stefan Beller
* 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