git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
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);

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