Hi Frank,
On Tue, 2020-10-20 at 20:45 -0400, Frank Ch. Eigler via Elfutils-devel wrote:
> Subject: [PATCH 2/2] debuginfod: suppress fdcache prefetching during dwz
> lookup
>
> From: Frank Ch. Eigler <f...@redhat.com>
>
> During a recent from-scratch reindexing of the rpm/deb corpus at
> debuginfod.elfutils.org, we found the fdcache chewed up an abnormal
> amount of $TMPDIR space. This was due to internal .dwz lookups, which
> triggered fdcache prefetching as for a webapi query, but there was not
> a timely fdcache eviction pass to clean it up again. Rather than add
> that pass, it's better to suppress the prefetching completely, as an
> internal .dwz search will only ever need that file, not any others
> from the same archive.
Makes sense. Only one comment:
> static struct MHD_Response*
> -handle_buildid_r_match (int64_t b_mtime,
> +handle_buildid_r_match (bool internal_req_p,
> + int64_t b_mtime,
> const string& b_source0,
> const string& b_source1,
> int *result_fd)
> @@ -1358,7 +1361,8 @@ handle_buildid_r_match (int64_t b_mtime,
> // 3) extract some number of prefetched entries (just into fdcache)
> // 4) abort any further processing
> struct MHD_Response* r = 0; // will set in stage 2
> - unsigned prefetch_count = fdcache_prefetch; // will decrement in stage 3
> + unsigned prefetch_count =
> + internal_req_p ? 0 : fdcache_prefetch; // will decrement in stage 3
>
> while(r == 0 || prefetch_count > 0) // stage 1, 2, or 3
> {
So we still setup the whole archive, but then don't actually iterate
through it. So shouldn't we check internal_req_p a little earlier and
just return from handle_buildid_r_match when it is set and we hit "no
match ... grumble, must process the archive"?
Cheers,
Mark
