Re: [PATCH v2 1/2] sha1_file: introduce close_one_pack() to close packs on fd pressure

[Junio C Hamano <gitster@pobox.com>]

Brandon Casey <drafnel@gmail.com> writes:

> On Thu, Aug 1, 2013 at 11:39 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> That makes me feel somewhat uneasy.  Yes, you can open/mmap/close
>> and hold onto the contents of a file still mapped in-core, and it
>> may not count as "open filedescriptor", but do OSes allow infinite
>> such mmapped regions to us?  We do keep track of number of open
>> windows, but is there a way for us to learn how close we are to the
>> limit?
>
> Not that I know of, but xmmap() does already try to unmap existing
> windows when mmap() fails, and then retries the mmap.  It calls
> release_pack_memory() which calls unuse_one_window().  mmap returns
> ENOMEM when either there is no available memory or if the limit of
> mmap mappings has been exceeded.

OK, so if there were such an OS limit, the unuse_one_window() will
hopefully reduce the number of open windows and as a side effect we
may go below that limit.

What I was worried about was if there was a limit on the number of
files we have windows into (i.e. having one window each in N files,
with fds all closed, somehow costs more than having N window in one
file with the fd closed).  We currently have knobs for total number
of windows and number of open fds consumed for packs, and the latter
indirectly controls the number of active packfiles we have windows
into.  Your proposed change will essentially make the number of
active packfiles unlimited by any of our knobs, and that was where
my uneasiness was coming from.