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

> 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.