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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id B6438E77188 for ; Fri, 3 Jan 2025 20:36:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 352F86B0089; Fri, 3 Jan 2025 15:36:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 302F76B008A; Fri, 3 Jan 2025 15:36:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1CB006B008C; Fri, 3 Jan 2025 15:36:58 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id F30D26B0089 for ; Fri, 3 Jan 2025 15:36:57 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 6A3FFAF7A4 for ; Fri, 3 Jan 2025 20:36:57 +0000 (UTC) X-FDA: 82967299674.04.6CA8D41 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.19]) by imf16.hostedemail.com (Postfix) with ESMTP id 1A548180007 for ; Fri, 3 Jan 2025 20:36:54 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=NyLktL78; spf=pass (imf16.hostedemail.com: domain of zide.chen@intel.com designates 192.198.163.19 as permitted sender) smtp.mailfrom=zide.chen@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1735936615; h=from:from:sender: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:dkim-signature; bh=j01j1Ru0cTwHYNiri5v+dRTfqfQ/WJZ/8wiinzFCke4=; b=MDz48gKZcTkMZuSPMZhOtujtIGA94BYCLvHImOWoGAy5LMBFX/G+KxNWhKNe0012HLnDti MCV+Ino1ZAoJRk/hUYzZ7k/BUpvZuAM1GoRSpt4XpcMdHMYU9TqVsEJRT38PEbXBwoGoPT 6NWIpwP8wN0pARghwPX/mkbbXb59whs= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=NyLktL78; spf=pass (imf16.hostedemail.com: domain of zide.chen@intel.com designates 192.198.163.19 as permitted sender) smtp.mailfrom=zide.chen@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1735936615; a=rsa-sha256; cv=none; b=FkDkQ64vnYLzrqpOdf8+iF7xBHer4+CbN2euWr+S4Ten7xrPIFw8zPccfNgmfHrktv5i/R yhASc/5OoXbQE/d17n36i111UrWrFBPMYgChpm5I5Fp/dOTu0APzBKU5O4IwIinlMA/EKH kd6jFFxZsqg8EgUL10r2nYPheuKwqCA= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1735936615; x=1767472615; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=mCtfy5uJAaCajLUrE5G8vQyO2NpDsuY9wDS9hBQpVCg=; b=NyLktL78zT6ZJNjSsADoRKmOS8Kp4Jzb/cy2fkq4vvL1ETzABEgMC5c/ 7tYaLOf0SUDXX5SbnDFjfs1q4fGl1Szu+NoVovd52UK1VT0NtRhldaP+8 FogmaFCVDdsyygPsozvNYy2QCNeDHBSzpsB3e95iZdYKMdtFsVT55h77T obbvRSryJnm4VKy/4iFYPNMBpatpLXb0zc0TbBcPeW2vH+dKmeSeKHQ5N XvxtPPxDovicG2lBDxYoRMoZtRPu+WvPe5I55x0ESfo4JZewEBqQn/vW8 KDFJ5iX6iZdfznX702amj0JDOwOITS6znHcILBRjuxWYpqInih+aGMJw/ g==; X-CSE-ConnectionGUID: JV3Lej6RSB2m0LBA5nzwDg== X-CSE-MsgGUID: OsbrYFMkSxidVuVBHhmpZg== X-IronPort-AV: E=McAfee;i="6700,10204,11304"; a="35426428" X-IronPort-AV: E=Sophos;i="6.12,286,1728975600"; d="scan'208";a="35426428" Received: from orviesa003.jf.intel.com ([10.64.159.143]) by fmvoesa113.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Jan 2025 12:36:51 -0800 X-CSE-ConnectionGUID: YN/5v/1XSEmBWLeUXna3JA== X-CSE-MsgGUID: M8g81aPcQ0mX/8DJq0Q3MA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,199,1725346800"; d="scan'208";a="106921252" Received: from soc-cp83kr3.clients.intel.com (HELO [10.24.8.92]) ([10.24.8.92]) by ORVIESA003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Jan 2025 12:36:51 -0800 Message-ID: Date: Fri, 3 Jan 2025 12:36:52 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] perf: map pages in advance To: Lorenzo Stoakes , David Hildenbrand Cc: Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , Kan Liang , linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Matthew Wilcox , Yi Lai References: <20241205082948.56212-1-lorenzo.stoakes@oracle.com> <65a04f0d-668b-47b6-a532-d1e11ef4835a@intel.com> <4ded2d63-03dd-498e-9810-690a9eff0c22@lucifer.local> <860a1ef0-678d-414d-8511-9695b90c3ca0@redhat.com> <74fd8a75-66c6-40a8-9ec3-d7aa74469755@intel.com> <2cb3d067-fe92-4bdf-ae79-b24810a4bc2e@redhat.com> <0d99b80e-0ae1-4d74-97b9-68fdc0029fb5@lucifer.local> Content-Language: en-US From: "Chen, Zide" In-Reply-To: <0d99b80e-0ae1-4d74-97b9-68fdc0029fb5@lucifer.local> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 1A548180007 X-Stat-Signature: e1chtay9o1ieg5unayquz61xt7kppm44 X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1735936614-298827 X-HE-Meta: U2FsdGVkX1+lsmak8pJ9vHBYE6J+GURN73CoMKXwfRSNrmOFm7IB+PMJkyJdVu6yKDfBqukDPNawxveJMTzV4DPy1kTfrgRn/EFgud9GwWUmuxzz0EFTZz+VlH78bhpVB4iNSNFbvWu4u2GN6BR1NZN9qLw/LOhfnDDfpRiapFUvBfT6NeiL1+dbJHnqEZ1t184u35v8aH1OrSWTdO2xSgAdUiFAfjC6GdR32O5PXy4813S3vIu5suReTzQEaKe2EQNuhoMn+kgQEoW6p0vIk8xa3S+Wd8tpYv6dY8isbSKBpvqc1xxyNRS72mUmViCLicEaSOat+MbI09OewkWc4zRtsXpGGmKMctRUAY3G6RA8vjeQHkiSOu4rLocBJ9+QsuTdLheUBuXNlcGCBtDkKOAWTGkmOWTZMtsi/onVfihXd6u9ky4LAX9Rv5WbsDtNEIfXQ71fDgaBW2jS8PRGeUA14E5eKheLerytbuHVZUMoQIeRg4CiGB7yUzV/21CD/XXQRZItNAaAJnQHBjv5Gu4QxfyTs148tz2C20KDhlBWN2hPRh2CMRpKDM70QLYm4xYBqApeVfb6arDObqXl3fc9unJZzXM4YZ1mPRFR/lzqV/K5roweObpkDzAFK02to6oI3Nr0/7lWTrcZLChAKb9loiSeKX5Tt/dHDOZnbyc4MuK9XxK8w2mB42uIzv0pZ8+mg+AIhUNawI54dfa5eGiJAC5JEEo4mRqyKTw8UfLIS5RxidVdqsbatcmDJbWKV05TCwEOOKwU8zcvucZsU91SHE6ZhsLQey3aUoSl6BrHbalAp+80GVQNUo6mHebTEZsHOODnD4bBYwa0ZsmdMFUf9xOj1hxVSIIl2eOaAY5bDDFv0qVTt2OYhRM5V1jNGEMjpIa+x+etkZY5B9kESDds8zgOs4dIZfFBdD2ocq9Wu1MeUxBDGZR30JXv+gkbVpTuJ8ciasQFv3U55eX vTwlhZZi c6/dlTOqU4xfVeVzkuO2aXiXqEcEHA5CmvRVNUnhMUufPuSGthiX+aXT6WFaGUDr3aEvJeTzJXHn6vIYs2gPk8KBnTuz+xb2xQFWoYkO7dbOAoKpmVGuCVDdLQLYwfjDuzuxy8z5MQ+TWiSG6aS3q/hruRfCiYF5JbSwmQd+PDuUmaQuFF897pM88i8ICg5sc6g34753bbgyCpKM= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 1/3/2025 6:45 AM, Lorenzo Stoakes wrote: > On Mon, Dec 23, 2024 at 10:12:42PM +0100, David Hildenbrand wrote: >> On 23.12.24 12:10, Lorenzo Stoakes wrote: >>> Peter - could you drop this patch for now until I have a chance to take a >>> look at this issue on my return on 2nd Jan? >>> >>> On Fri, Dec 20, 2024 at 10:53:14PM +0100, David Hildenbrand wrote: >>>> On 20.12.24 22:29, David Hildenbrand wrote: >>>>> On 20.12.24 20:36, Chen, Zide wrote: >>>>>> >>>>>> >>>>>> On 12/20/2024 1:56 AM, David Hildenbrand wrote: >>>>>>> On 20.12.24 10:31, Lorenzo Stoakes wrote: >>>>>>>> On Thu, Dec 19, 2024 at 01:17:44PM -0800, Chen, Zide wrote: >>>>>>>> >>>>>>>>> With this patch, it seems perf tool has some problems in capturing the >>>>>>>>> kernel data with Intel PT. >>>>>>>>> >>>>>>>>> Running the following commands, the size of perf.data is very small, and >>>>>>>>> perf script can't find any valid records. >>>>>>>>> >>>>>>>>> perf record -e intel_pt//u -- /bin/ls >>>>>>>>> perf script --insn-trace >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I'm on leave (and should really go back to relaxing :>), returning on 2nd >>>>>>>> Jan so can't really dig into this. >>>>>>>> >>>>>>>> But I tried it on my intel box and it 'works on my machine' with and >>>>>>>> without patch with commands provided, so I'm not sure this is actually a >>>>>>>> product of this change (which shouldn't impact this). >>>>>>> >>>>>>> Zide Chen, can you try with and without this patch to see if it >>>>>>> introduces the issue? >>>>>> >>>>>> Yes, I re-did the test on a SPR server, and the result is same. Without >>>>>> the patch, it went well; But with it, "perf script --insn-trace" doesn't >>>>>> show valid records. >>>>>> >>>>>> This time I tested it on the clean 6.13-rc1 tag, base commit >>>>>> 40384c840ea1944d7c5a392e8975ed088ecf0b37 >>>>>> >>>>>> Also, with this patch, running tools/perf/tests/shell/test_intel_pt.sh: >>>>>> >>>>>> Error: >>>>>> The - data has no samples! >>>>> >>>>> I just tested it on 6.13-rc1 vs. 6.13-rc1 with this patch. >>>>> >>>>> Indeed, there is quite difference. Below are the main parts that changed, only. >>>>> >>>>> We seem to be recording data, but maybe what we record gets corrupted somehow? >>>> >>>> Huge parts of the new file are full of 0s. Either we are mapping the wrong >>>> pages, or reading from the pages (via PFNMAP) does not work as expected. >>>> >>> >>> Thanks David, and apologies Zide, appears there is an issue here clearly. >>> >>> Could you try this with sudo operations? I was doing this locally and I >>> wonder if there is now a permissioning error? >> >> I ran it under root. >> >>> >>> I'd be surprised if pfn map would cause an issue here as it should just >>> directly map the kernel memory, however if the PT code assumes there will >>> be faults there could be an issue. I did take a brief look at this last >>> week and it seems the PT stuff relies on the aux functionality, so that >>> could also be a source of problems here. >> >> I started a bit at that code, no clue yet what's happening. >> >> I was wondering if we end up mapping the wrong pages, meaning: the pages at >> mmap time end up being different to the pages later at fault time. The code >> is a bit confusing, but I thought we cannot change the effective event/pages >> while we have an active mmap. Maybe there is some corner case ... > > OK I figured it out... it's a very silly mistake on my part (oh how this is so > often the case :). > > When we map the pages, we do not offset by vma->vm_pgoff when looking up the > page, so if you map with an offset (as presumably the intel pt stuff is), it is > then retrieving the wrong pages). > > This also resolves the apparent need for sudo... > > Very silly mistake. Apologies :>) > > I will send a v4 in a second. > > Zide - could you give v4 a test when I send it out just to confirm it resolves > your issue? I will cc- you on this. > > Thanks again for your report, and apologies for the noise! I can confirm that v4 works for my Intel PT tests! -Zide >> >> Nothing else really jumped at me ... moving the mapping og pages after the >> event_mapped() callback also didn't change anything. >> >>> >>> I am on leave at the moment returning on 2nd Jan, I will look at this as a >>> priority when I return, as you can see above I've asked Peter to drop this >>> for now. >> >> Enjoy your time off an Happy Holidays! >> >> -- >> Cheers, >> >> David / dhildenb >> > > Cheers, Lorenzo