From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dd14210.kasserver.com (dd14210.kasserver.com [85.13.138.83]) by sourceware.org (Postfix) with ESMTPS id 32E883858D28 for ; Fri, 8 Apr 2022 22:23:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 32E883858D28 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=milianw.de Authentication-Results: sourceware.org; spf=none smtp.mailfrom=milianw.de Received: from milian-workstation.localnet (p54a1bbed.dip0.t-ipconnect.de [84.161.187.237]) by dd14210.kasserver.com (Postfix) with ESMTPSA id 3382A240A0A; Sat, 9 Apr 2022 00:23:33 +0200 (CEST) From: Milian Wolff To: Aaron Merey Cc: Mark Wielaard , elfutils-devel@sourceware.org Subject: Re: caching failed lookups of debuginfo? Date: Sat, 09 Apr 2022 00:23:32 +0200 Message-ID: <274959185.zvkkRjgryB@milian-workstation> In-Reply-To: <2180828.1FMjDaRedj@milian-workstation> References: <4448277.fIUe8AKecr@milian-workstation> <2180828.1FMjDaRedj@milian-workstation> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart8135321.GP4inXlKNz"; micalg="pgp-sha256"; protocol="application/pgp-signature" X-Spam-Status: No, score=1.0 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: elfutils-devel@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Elfutils-devel mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2022 22:23:36 -0000 --nextPart8135321.GP4inXlKNz Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii"; protected-headers="v1" From: Milian Wolff To: Aaron Merey Cc: Mark Wielaard , elfutils-devel@sourceware.org Subject: Re: caching failed lookups of debuginfo? Date: Sat, 09 Apr 2022 00:23:32 +0200 Message-ID: <274959185.zvkkRjgryB@milian-workstation> In-Reply-To: <2180828.1FMjDaRedj@milian-workstation> On Freitag, 8. April 2022 23:56:15 CEST Milian Wolff wrote: > Which in turn points at the code that does cache cleanup in > `debuginfod_query_server`. I now used `rr` to record such a bogus run and I > clearly see that `(time(NULL) - st.st_mtime <= cache_miss)` is false and it > goes into the unlink case. > > I'll try to debug this further now - I definitely do not wait 600s inbetween > these runs here... I compiled elfutils with debug output, and here's what I can see when I run `debuginfod-find`: time(NULL) = 1649455510 st.st_mtime = 1649448650 delta = 6860 cache_miss = 600 The longer I wait, the bigger the delta becomes - i.e. for every second I wait, the `delta` increases by one. And I think I know where this comes from: ``` # first we stat the target cache path if (stat(target_cache_path, &st) == 0 { # then we pass _the same st_ to debuginfod_config_cache(cache_miss_path, cache_miss_default_s, &st) # which internally will do stat(config_path, st) # then we check the time delta time(NULL) - st.st_mtime <= cache_miss ``` I.e. when we check the time delta, we only take the time stamp of the `config_path` into account - the time stamp of the `target_cache_path` is ignored. I mount my filesystems with relatime (old advise for ssd's, probably not relevant anymore?). I guess that's the issue then? Can we change the above code to store the `st.st_mtime` for `target_cache_path` and use that for comparison purposes? That fixes the issue for my case. If this is acceptable, I'll provide a patch. Thanks -- Milian Wolff mail@milianw.de http://milianw.de --nextPart8135321.GP4inXlKNz Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEezawi1aUvUGg3A1+8zYW/HGdOX8FAmJQteQACgkQ8zYW/HGd OX9WDA//S/6muRU4V9129qNErvjDuPEAc2TGnVbKtkFFht4PFdEpNHGO0g0C7yAJ L+/1TxNa3nnKQaAmVcaBI2iiOYtGova5/zM4kyp7KnrhDQImwowVs6Mnu41WaOJA vT2LPOh8l+U5vCqXPbYw03ELiK0woJaEhJtY9jNDo2G8/6muV2xvNi0sa/yNNfEM IvesRyKfYzwmD6q4gKmL3dAahItquRD9NhICY/QGobkmSgzPPwsaFtyFOWkdJ9DG iGlICmLBrkOaFugvpgEKEGVRfb7fxPzK/BAQsgB+cSKsSPWSyOkf/wDSLaZLhN1b tbl47/793A+sushixtGF44vgwgJHkP3kar3jPv2bndGOEgzqkMbs1mfZZbibD73n qqhtL9iq2Ux06unVCNXiTz81HObUYRbmEdik7G5EIAOPzHtBasZxLZd1ja0bxSgX rdLN2RccbES8uK/yabGojgcL4Y0tXyd9hNXEq21zgIAws8zb4iNRv406YGI+Qw1X lw6YZo9c060E1JLLWqqMTU16RBu9smnilYsofEc3JeMXdGZ8DKjX0FNuIJy5J+ya DxRBAac2HhNqUjvmnDnOZojoqzLWIXaiFHnROULHvRy/4vhpJKLI3YZkywFHVgyo 6eV5h19GFSCEgUi3KJU1NK9uc7Ey88FaI4l5UlC6OIMYjBHU+Gs= =3Utx -----END PGP SIGNATURE----- --nextPart8135321.GP4inXlKNz--