From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) by sourceware.org (Postfix) with ESMTPS id 9BBAF3854817 for ; Mon, 20 Sep 2021 13:17:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9BBAF3854817 Received: by mail-qk1-x72b.google.com with SMTP id bk29so42266949qkb.8 for ; Mon, 20 Sep 2021 06:17:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=i3ckuDgGtSK+QZ2ColCswAAyF0+0Fo75iKNbAjxLy/w=; b=0+Al/TE/1OiXr19rMfGFAN/hSPkzQTwVCkfYwO1YETZOaTccsWRZcNKrAQFMLGmGyI XVZYU8JqhNM+Gz07kWrOzRjoo3GYOd/NyjTbSYwfSZLWoh+ueDVLC0JwnIUBYNJTkjTX D4AmMWPr/CrQzQkIObeG4lv7kWQ31x0iTVMqkDL9g8sXMiEwwM7qAm020ZQCd2F7Bmnf 9uZkCaEMCzcVqvbwQt/MumNdxTMk9aHZG0UJ0DJMqih+jGgbc+H8Ulc4lWAAo5Agq5Hj TvzGcNy5WYuQk2sf43eGDtLJJVSweZQc3mzWCygifXgRoEy/Wm9UDNGHqQLZ6BN7difK ekqg== X-Gm-Message-State: AOAM5326r+485zvrQ7wYZn6NCo4kKIN8AeNlj4OEhssAVLHRoQS+KpPd nphsJA2JkRZ9h8PNMjr4vkdmNmOxNO1vG3bVyYQd4w== X-Google-Smtp-Source: ABdhPJz+hUvWbZ6PksojxC2ioTeIUDWIObBlhvadQKnG6Rgvi05LvWzrqr7eWyg+heHlF/PFaLcAdMroDvsmXVUyIvI= X-Received: by 2002:a5b:f03:: with SMTP id x3mr32591386ybr.546.1632143821151; Mon, 20 Sep 2021 06:17:01 -0700 (PDT) MIME-Version: 1.0 References: <2b184d53-9044-0e6c-b4db-b87606478026@web.de> In-Reply-To: From: Adhemerval Zanella Date: Mon, 20 Sep 2021 10:16:50 -0300 Message-ID: Subject: Re: Checking special execution durations for the determination of mountable file systems To: Markus Elfring Cc: Adhemerval Zanella via Libc-help Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Sep 2021 13:17:04 -0000 On Sun, Sep 19, 2021 at 11:04 AM Markus Elfring wro= te: > > > The statvfs() calls statfs() which in turn is a syscall. There is some > > memory copy involved on __internal_statvfs64(), > > but it's runtime should be negligible. > > Are any test cases available for these functions? We have some very basic tests (io/tst-statvfs.c) and statfs is used internally for pathconf (_PC_NAME_MAX), but besides there is not much coverage. It might be possible to cross-reference procfs/sysfs information with the syscall returns information to check if it behaves correctly. The LTP [1] has more tests testcases/kernel/syscalls/statfs/statfs0*.c and testcases/kernel/syscalls/statvfs/statvfs0*.c but I am not sure which is the total coverage. > > > Which impression did you get from the displayed execution durations? That is something in the kernel, since glibc is just a wrapper over the sys= call. > > > > I would check with Linux perf with kernel probing enabled to see exactl= y > > what is happening. > > I can eventually increase the tracing depth for the analysis tool =E2=80= =9Cuftrace=E2=80=9D > (if further details from Linux function calls would be really helpful > for such a clarification approach). If kernel it is still the culprit here as I think it is, it would be better to check with kernel developers what might be happening here. My wild guess is > > Regards, > Markus [1] https://github.com/linux-test-project/ltp