From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 51074385841E for ; Tue, 13 Jun 2023 15:22:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 51074385841E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1686669733; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=YMd6q9dR2LsMkRWEnuZnLcgKv51W7j1YNYXeMdVjAHw=; b=Tfwsrnjs2qbFgxqVkHHSy5Qg/QTOxlDOsdGLSK3J4zRs9aEmRFLbXYy71NWApiRPKJ308i Fte8UWq0dk/uR16lqcHIgq5cuoWjok1MxS9NwLyw5al73KZFcZ4J9Nq89lQ0BZ7gs1nQ/V oPHstllXeRd/8m/7m/UUKU1/5GN/7PE= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-187-syB-6Hi5O2u8GenDzMmqZg-1; Tue, 13 Jun 2023 11:22:12 -0400 X-MC-Unique: syB-6Hi5O2u8GenDzMmqZg-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id DED87185A797; Tue, 13 Jun 2023 15:22:11 +0000 (UTC) Received: from [10.22.32.98] (unknown [10.22.32.98]) by smtp.corp.redhat.com (Postfix) with ESMTP id BB2F6492C38; Tue, 13 Jun 2023 15:22:11 +0000 (UTC) Message-ID: <4893d129-6569-4318-cf3b-7821bef98441@redhat.com> Date: Tue, 13 Jun 2023 11:22:11 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Cc: wcohen@redhat.com, "systemtap@sourceware.org" Subject: Re: vfs.add_to_page_cache not working anymore? To: Daire Byrne References: From: William Cohen In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.10 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 6/12/23 11:39, Daire Byrne via Systemtap wrote: > I have recently updated my kernel (v6.3) and with systemtap version (v4.8), > an old systemtap script I was using has stopped working. > > It looks like I was counting pages added via vfs.add_to_page_cache as a > means to work out file reads (over NFS) per pid. > > But this function no longer seem to hit at all for me anymore: > > stap -e 'probe vfs.add_to_page_cache { printf("Works.\n"); exit() }' > > I am aware that v4.9 is the latest systemtap, but I have been struggling to > get it to compile with the new jupyter stuff (my python version is too old). > > Anyway, any help or pointers for vfs.add_to_page_cache greatly appreciated. > > Daire > Hi, Switching to systemtap-4.9 is probably not going to change the results in this case as there are no changes in tapset/linux/vfs.stp between 4.8 and 4.9. Unfortunately, the kernels changes over time and some functions probed by the tapset change over time or the way they are used by other parts of the kernel changes. The vfs.add_to_page cache in the vfs.stp has three possible functions it probes: add_to_page_cache_locked, add_to_page_cache_lru, and add_to_page_cache. The first two functions were added due to kernel commit f00654007fe1c15. Did some git commit archeology and only add_to_page_cache_lru is in the kernel due to kernel git commit 2bb876b58d593d7f2522ec0f41f20a74fde76822. The following URL show where add_to_page_cache_lru is used in 6.2.16 kernels nfs and can provide some method of seeing how the nfs related functions get called: https://elixir.bootlin.com/linux/v6.2.16/A/ident/add_to_page_cache_lru As far as specifically what has changed to cause vfs.add_to_page_cache not to trigger for NFS operations I am not sure. For the 6.2 kernel it might be good to get a backtrace of the triggering of it and then use that information to see what has changed in the functions on the backtrace. stap -ldd -e 'probe vfs.add_to_page_cache { print_backtrace(); printf("Works.\n"); exit() }' -Will