From: Junio C Hamano <gitster@pobox.com>
To: Brandon Casey <bcasey@nvidia.com>
Cc: <git@vger.kernel.org>, <peff@peff.net>, <spearce@spearce.org>,
<sunshine@sunshineco.com>, Brandon Casey <drafnel@gmail.com>
Subject: Re: [PATCH v2 1/2] sha1_file: introduce close_one_pack() to close packs on fd pressure
Date: Thu, 01 Aug 2013 10:12:56 -0700 [thread overview]
Message-ID: <7vsiyts5bb.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <1375300297-6744-1-git-send-email-bcasey@nvidia.com> (Brandon Casey's message of "Wed, 31 Jul 2013 12:51:36 -0700")
Brandon Casey <bcasey@nvidia.com> writes:
> If the refs are loose, then upload-pack will read each ref from the
> pack (allocating one or more mmap windows) so it can peel tags and
> advertise the underlying object. If the refs are packed and peeled,
> then upload-pack will use the peeled sha1 in the packed-refs file and
> will not need to read from the pack files, so no mmap windows will be
> allocated and just like with receive-pack, unuse_one_window() will
Even though what it says is not incorrect, the phrasing around here,
especially "so it can", confused me in my first reading. It reads
objects "in order to" peel and advertise (and as a side-effect it
can lead to windows into packs that eventually help relieaving the
fd pressure), but a quick scan led me to misread it as "so it can do
peel and advertise just fine", which misses the point, because it is
not like we are having trouble peeling and advertising.
Also, the objects at the tips of refs and the objects they point at
may be loose objects, which is very likely for branch tips. The fd
pressure will not be relieved in such a case even if these refs were
packed.
I've tentatively reworded the above section like so:
... If the refs are loose, then upload-pack will read each ref
from the object database (if the object is in a pack, allocating
one or more mmap windows for it) in order to peel tags and
advertise the underlying object. But when the refs are packed
and peeled, upload-pack will use the peeled sha1 in the
packed-refs file and will not need to read from the pack files,
so no mmap windows will be allocated ...
> +static int close_one_pack(void)
> +{
> + struct packed_git *p, *lru_p = NULL;
> + struct pack_window *mru_w = NULL;
> +
> + for (p = packed_git; p; p = p->next) {
> + if (p->pack_fd == -1)
> + continue;
> + find_lru_pack(p, &lru_p, &mru_w);
> + }
> +
> + if (lru_p) {
> + close_pack_windows(lru_p);
> + close(lru_p->pack_fd);
> + pack_open_fds--;
> + lru_p->pack_fd = -1;
> + if (lru_p == last_found_pack)
> + last_found_pack = NULL;
> + return 1;
> + }
> +
> + return 0;
> +}
OK, so in this codepath where we know we are under fd pressure, we
find the pack that is least recently used that can be closed, and
use close_pack_windows() to reclaim all of its open windows (if
any), which takes care of the accounting for pack_mapped and
pack_open_windows, but we need to do the pack_open_fds accounting
here ourselves. Makes sense to me.
Thanks.
> void unuse_pack(struct pack_window **w_cursor)
> {
> struct pack_window *w = *w_cursor;
> @@ -777,7 +838,7 @@ static int open_packed_git_1(struct packed_git *p)
> pack_max_fds = 1;
> }
>
> - while (pack_max_fds <= pack_open_fds && unuse_one_window(NULL, -1))
> + while (pack_max_fds <= pack_open_fds && close_one_pack())
> ; /* nothing */
>
> p->pack_fd = git_open_noatime(p->pack_name);
next prev parent reply other threads:[~2013-08-01 17:13 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-30 4:05 [PATCH] sha1_file: introduce close_one_pack() to close packs on fd pressure Brandon Casey
2013-07-30 7:51 ` Eric Sunshine
2013-07-30 15:39 ` Junio C Hamano
2013-07-30 19:52 ` Jeff King
2013-07-30 22:59 ` Brandon Casey
2013-07-31 19:51 ` [PATCH v2 1/2] " Brandon Casey
2013-07-31 19:51 ` [PATCH 2/2] Don't close pack fd when free'ing pack windows Brandon Casey
2013-07-31 21:08 ` Antoine Pelisse
2013-07-31 21:21 ` Fredrik Gustafsson
2013-07-31 21:31 ` Brandon Casey
2013-07-31 21:44 ` Fredrik Gustafsson
2013-07-31 21:23 ` Brandon Casey
2013-07-31 21:28 ` Thomas Rast
2013-08-01 17:12 ` Junio C Hamano [this message]
2013-08-01 18:01 ` [PATCH v2 1/2] sha1_file: introduce close_one_pack() to close packs on fd pressure Brandon Casey
2013-08-01 18:39 ` Junio C Hamano
2013-08-01 19:16 ` Brandon Casey
2013-08-01 19:23 ` Brandon Casey
2013-08-01 20:02 ` Junio C Hamano
2013-08-01 20:37 ` Brandon Casey
2013-08-02 5:36 ` [PATCH v3] " Brandon Casey
2013-08-02 16:26 ` Junio C Hamano
2013-08-02 17:12 ` Brandon Casey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vsiyts5bb.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=bcasey@nvidia.com \
--cc=drafnel@gmail.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
--cc=spearce@spearce.org \
--cc=sunshine@sunshineco.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).