From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F24D6C432C1 for ; Tue, 24 Sep 2019 18:56:02 +0000 (UTC) Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9714A214AF for ; Tue, 24 Sep 2019 18:56:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9714A214AF Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=vt.edu Authentication-Results: mail.kernel.org; spf=fail smtp.mailfrom=kernelnewbies-bounces@kernelnewbies.org Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.92.2) (envelope-from ) id 1iCpyK-0001rx-4e; Tue, 24 Sep 2019 14:55:36 -0400 Received: from omr1.cc.ipv6.vt.edu ([2607:b400:92:8300:0:c6:2117:b0e] helo=omr1.cc.vt.edu) by shelob.surriel.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.2) (envelope-from ) id 1iCpyH-0001rr-Ab for kernelnewbies@kernelnewbies.org; Tue, 24 Sep 2019 14:55:33 -0400 Received: from mr1.cc.vt.edu (inbound.smtp.ipv6.vt.edu [IPv6:2607:b400:92:9:0:9d:8fcb:4116]) by omr1.cc.vt.edu (8.14.4/8.14.4) with ESMTP id x8OItV5X027072 for ; Tue, 24 Sep 2019 14:55:32 -0400 Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) by mr1.cc.vt.edu (8.14.7/8.14.7) with ESMTP id x8OItQw1016340 for ; Tue, 24 Sep 2019 14:55:31 -0400 Received: by mail-qt1-f197.google.com with SMTP id e13so3045590qto.18 for ; Tue, 24 Sep 2019 11:55:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:in-reply-to:references :mime-version:content-transfer-encoding:date:message-id; bh=VYC2vkmuXFSzO2YFDET+pLLTEfBAYqn5n4jY/TSGYIY=; b=UATg8/yCcxeVHK26BVO684a1rrgxfI2tTuPGU0ghp1Cj4gSMfZ9lQNY500Gsal/Efa bVtIFextlj0cdET4CGKj1ov7JcZKPZlp9K42mcXa9mqhxaIc004OuFCAKY/syPlGttoK POJa+yEPOkH1QQU4KUhFXd6Fowc6CBUwxMpkaLloxwkVMwFXgxh2fc/UWicHQxicLymS 7/Kw2MDCk892/xcE8l9bmWkU2z0tAy/UxldDjM8TqucmZziO/117iHIKkQWBzFK+G6ND VXi1DJlw376P5DBKDJrasmcpE5ivnH/BW+hUIeVyv/z8+aaI5oGcVp+CvSvxaZIrSfHR 5rkQ== X-Gm-Message-State: APjAAAWoozfiQTitgFLbXb+qhaAtWwANy6WN5+QYH3sLBXe3D4fPZXZu vab5l3Tdsyh1pDl25EM3aqOF0PPt3sVhEw9kILjMODc9NvSkQP4D5zY8jkxCUaXt2LI7XdGguGn yhcLNSlcYnl9QPDGWLNa+boLjKMPkPAV4p1xGOeQ= X-Received: by 2002:a37:65d2:: with SMTP id z201mr4155740qkb.355.1569351326124; Tue, 24 Sep 2019 11:55:26 -0700 (PDT) X-Google-Smtp-Source: APXvYqzhYs2fQeA6pnYTbbfaBD9CrALaYqJUmg5ww4zLZU9+OCvMF0oMCh76kkMIgISeqp31Wbmx/w== X-Received: by 2002:a37:65d2:: with SMTP id z201mr4155718qkb.355.1569351325766; Tue, 24 Sep 2019 11:55:25 -0700 (PDT) Received: from turing-police ([2601:5c0:c001:4341::359]) by smtp.gmail.com with ESMTPSA id q44sm1668594qtk.16.2019.09.24.11.55.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Sep 2019 11:55:22 -0700 (PDT) From: "Valdis Kl=?utf-8?Q?=c4=93?=tnieks" X-Google-Original-From: "Valdis Kl=?utf-8?Q?=c4=93?=tnieks" X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7+dev To: Sahibzada Irfanullah Subject: Re: Generating Log of Guest Physical Addresses from a Kernel Function and Perform Analysis at Runtime In-Reply-To: References: <242780.1569323798@turing-police> Mime-Version: 1.0 Date: Tue, 24 Sep 2019 14:55:21 -0400 Message-ID: <264319.1569351321@turing-police> Cc: kernelnewbies@kernelnewbies.org X-BeenThere: kernelnewbies@kernelnewbies.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Learn about the Linux kernel List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6591244252675724065==" Errors-To: kernelnewbies-bounces@kernelnewbies.org --===============6591244252675724065== Content-Type: multipart/signed; boundary="==_Exmh_1569351321_12454P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit --==_Exmh_1569351321_12454P Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tue, 24 Sep 2019 20:26:36 +0900, Sahibzada Irfanullah said: > After having a reasonable amount of log data, If you're trying to figure out how the kernel memory manager is working, = you're probably better off using 'perf' or one of the other tracing tools alrea= dy in the kernel to track the kernel memory manager. For starters, you can get = those tools to give you things like stack tracebacks so you know who is asking = for a page, and who is *releasing* a page, and so on. Of course, which of these tools to use depends on what data you need to a= nswer the question - but simply knowing what physical address was involved in a= page fault is almost certainly not going to be sufficient. > I want to perform some type of analsys at run time, e.g., no. of unique= > addresses, total no. of addresses, frequency of occurences of each addr= esses > etc. So what =22some type of analysis=22 are you trying to do? What question(s= ) are you trying to answer?=20 The number of unique physical addresses in your system is dictated by how= much RAM you have installed. Similarly for total number of addresses, although= I'm not sure why you list both - that would mean that there is some number of= non-unique addresses. What would that even mean? The number of pages actually available for paging and caching depends on = other things as well - the architecture of the system, how much RAM (if any) is= reserved for use by your video card, the size of the kernel, the size of = loaded modules, space taken up by kmalloc allocations, page tables, whether any processes have called mlock() on a large chunk of space, whether the page= s are locked by the kernel because there's I/O going on, and then there's thing= s like mmap(), and so on. The kernel provides /proc/meminfo and /proc/slabinfo - you're going to wa= nt to understand all that stuff before you can make sense of anything. Simply looking at the frequency of occurrences of each address is probabl= y not going to tell you much of anything, because you need to know things like the total working and resident set sizes for the process and other contex= t. For example - you do the analysis, and find that there are 8 gigabytes of= pages that are constantly being re-used. But that doesn't tell you if there ar= e two processes that are thrashing against each other because each is doing hea= vy repeated referencing of 6 gigabytes of data, or if one process is wildly = referencing many pages because some programmer has a multi-dimensional array and is walking across the array with the indices in the wrong order i_max =3D 4095; j_max =3D 4095; for (i =3D 0, i < i_max; i++) for j =3D 0, j < j_max; j++) =7Bsum +=3D fo= o=5Bi=5D=5Bj=5D=7D If somebdy is doing foo=5Bj=5D=5Bi=5D instead, things can get ugly. And = if you're mixing with Fortran code, where the semantics of array references is reve= rse and you *want* to use 'foo=5Bj=5D=5Bi=5D' for efficient memory access, it= 's a bullet loaded in the chamber and waiting for somebody to pull the trigger. Not that I've ever seen *that* particular error happen with a programmer processing 2 terabytes of arrays on a machine that only had 1.5 terabytes= of RAM. But I did tease the person involved about it, because they *really*= should have known better. :) So again: What question(s) are you trying to get answers to? --==_Exmh_1569351321_12454P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Comment: Exmh version 2.9.0 11/07/2018 iQIVAwUBXYpmmAdmEQWDXROgAQKcfw//fVQs+pF2v+VOWz4EWfDQwBojq1AmpxZQ FK0C1lAT8F6TkmbiyUPVfE3qZxXxJ763ArAkLXB+MMdpfPKLBUdUExwgczpKr4F9 CODeeBfDDMToTLPB565TeKrAQFi7HyzwPQ0AfOdln+Ml3FOCFbhTMHYgdtPQnzT2 aHfgfdUPEHHEdAxWWJa1pO2rYnOWdyEvZyp2B4pyD1pdzA+7kb299MPTlb5tdh7X NQw+Ua4XSYT31MQkr8CC+X7Zto++PdtsV/ATzedNv/4MC5mVFF3CN5CHHpuFjw/5 vrzNx9hWgV8xmNNIUCOO3L9ToeuHOPKPIsDWCr5BA3LOuvFYHzQ6vv7cBPv35LXR GvG+SG2iOPE1TbC4D5HgS2oeDc/TT7vcVCmjwzu1ob9Wh0H9XmySURW7oHvJQGR+ lK7odHcQtWBcBSq2ilX0aV2Iz8+5BH0Qmw7+aG2yYXMK+fAqk4UrF/ROtnjJv5P3 GOKbpfHbJE3tOFNTEndP3bmqaxuE1IlEo082U6wrdP+3s/YaD/IchyCKcLDfvElH d3oCIoYJjaFqBGeWy1NlsfhIw5a50/A35iLlDbXYztamkH/wDlXR7lGystmdIk9U xann2RAVD6vajjwC6+zSuoQS6p+stYtalPTmmjpzgd9Pf+o3Q3jfitWxGRWP+qV0 fH5itqtickE= =Yd0n -----END PGP SIGNATURE----- --==_Exmh_1569351321_12454P-- --===============6591244252675724065== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies --===============6591244252675724065==--