Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp890562pxu; Wed, 2 Dec 2020 06:08:58 -0800 (PST) X-Google-Smtp-Source: ABdhPJyAmJWTP0CVjf/rSB8DSeJtc/ExbTWPZQcw1bzoyr4FY+LAfQk1Of1n4FGVSXZb7jAyEIEq X-Received: by 2002:a50:e042:: with SMTP id g2mr65612edl.292.1606918138183; Wed, 02 Dec 2020 06:08:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606918138; cv=none; d=google.com; s=arc-20160816; b=zd1aYZzbacdRmoAkFJHPVkrJcn0nLlWaJLhcacDQhlfv9i7Wcejnk73UDn9vOo01rJ yYDfT+4aFVfQwdvDAZ57qdPYEVvD9ouwnQnR3trJgG66h3O0mwOyyMxWPNVyesnwFDnf O2HOaEfVh8aZ12LFEUQdqjB686XGzHN5an8G9pAWfo4H7A2Wly/x38vb7KyLdfpj5Q8Q /5yWBLQnV3xCQOg/jFn2G79Wd1YFX7TKgPGBTMjm6t///YN4WlD1ENLbeY+0PUgwngDt mfd6nPqQCOtSVlRkFNOuAg0Js8WBiPXpFRfA6EVXkaSrqdkmDCKBAyh6P/QfDOW1Cbe4 3VeQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:organization :from:references:cc:to:subject:ironport-sdr:ironport-sdr; bh=WujR1u6R5gVVGx0iLX2OYeEytxKbwGFFXoNZ1gr4GMY=; b=Bq9JO+CShqlAJoQ5Mp28O/82dKlZp9v4j7WPkW6E5Ofwdk6wmicIxo+sL+h0KbpZet Fl3BJCEvPCgmS7z7Z3YbqxRhIOhlqYY641dSVCguDcIrE2wAegbdB8bUh7fYAofKITsH Xwyf+xu90B3XdLkYXg6RsZWG0b2g7HSUDb9RgtBTqoHOha09Yz+DrtiSwITWXmsY/54D mJ8qfIiPHkK9fd9sqTZW5az49Hpkly4kshgGPNdY+8+7NZfNq4zpJ6u1EBF1tXSC0ZCX 3jVkAQwqUR7P+y+lhrTeEstJW2dmJXzdsNBrweRDNO+eF1MpXsQjZAlz5ea5eVhRLeH8 /SYg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g25si17007ejp.67.2020.12.02.06.08.29; Wed, 02 Dec 2020 06:08:58 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727460AbgLBOGe (ORCPT + 99 others); Wed, 2 Dec 2020 09:06:34 -0500 Received: from mga05.intel.com ([192.55.52.43]:2674 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726734AbgLBOGe (ORCPT ); Wed, 2 Dec 2020 09:06:34 -0500 IronPort-SDR: 8rSQEkp0cpFFZy12qX+lNyw12YuQrOG7X1gx5PVNymU598mHJQA+SY11jUgHOUdZIh7rFc3nlG kTrSK6otDAfg== X-IronPort-AV: E=McAfee;i="6000,8403,9822"; a="257730209" X-IronPort-AV: E=Sophos;i="5.78,386,1599548400"; d="scan'208";a="257730209" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Dec 2020 06:04:52 -0800 IronPort-SDR: G7l6JHhoAIF2UNdPdYNAse8N3pasjeamrjFwJM31XrN7HrJWUnsW/4dP4zTcjRg4Q7Y5Q+K7fx /ZcPt+ra2/PA== X-IronPort-AV: E=Sophos;i="5.78,386,1599548400"; d="scan'208";a="550070268" Received: from abaydur-mobl1.ccr.corp.intel.com (HELO [10.249.229.109]) ([10.249.229.109]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Dec 2020 06:04:49 -0800 Subject: Re: [PATCH v2 1/3] Revert "perf session: Fix decompression of PERF_RECORD_COMPRESSED records" To: Alexei Budankov , Jiri Olsa , Petr Malat Cc: linux-kernel@vger.kernel.org, Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Mark Rutland , Alexander Shishkin , Namhyung Kim , Adrian Hunter , Kan Liang References: <20201124095923.3683-1-oss@malat.biz> <20201124102919.15312-1-oss@malat.biz> <20201124143645.GD2088148@krava> <20201124181519.GA29264@ntb.petris.klfree.czf> <20201130114020.GA29476@ntb.petris.klfree.czf> <20201201190928.GB3169083@krava> <90d5469d-2591-44bf-70c4-edc1b2750935@huawei.com> <1ee1c9b6-516f-cee1-1b37-388fb5507cd3@huawei.com> From: "Bayduraev, Alexey V" Organization: Intel Corporation Message-ID: <545dfd5b-670a-a215-4484-29fe10b18517@linux.intel.com> Date: Wed, 2 Dec 2020 17:04:47 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <1ee1c9b6-516f-cee1-1b37-388fb5507cd3@huawei.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, I was able to reproduce "Couldn't allocate memory for decompression" on 32-bit perf with long perf.data. On my side mmap() in perf_session__process_compressed_event() fails with ENOMEM, due to exceeded memory limit for 32-bit applications. This happens with or without Petr's patch. As I can see, these mappings are only released in perf_session__delete(). We should think how to release them early. On 02.12.2020 0:28, Alexei Budankov wrote: > > Eventually sending to the proper Alexey's address. > > On 02.12.2020 0:04, Alexei Budankov wrote: >> >> On 01.12.2020 22:09, Jiri Olsa wrote: >>> On Mon, Nov 30, 2020 at 12:40:20PM +0100, Petr Malat wrote: >>>> Hi Jiří, >>>> were you able to reproduce the issue? I may also upload perf-archive >>>> if that would help. >>> >>> oh yea ;-) seems like those 2 commits you reverted broke 32 bits >>> perf for data files > 32MB >>> >>> but the fix you did does not work for Alexey's test he mentioned >>> in the commit: >>> >>> $ perf record -z -- some_long_running_workload >>> $ perf report --stdio -vv >>> >>> it's failing for me with: >>> >>> # ./perf report >>> Couldn't allocate memory for decompression >>> 0xfe6f3a [0x60]: failed to process type: 81 [Operation not permitted] >>> Error: >>> failed to process sample >>> # To display the perf.data header info, please use --header/--header-only options. >>> # >>> >>> I think that's why here's special handling for compressed >>> events, but I'll need to check on that in more detail, >>> I was hoping for Alexey to answer ;-) >> >> Sorry for delay. Alexey Bayduraev could possibly help with that sooner. >> Alexey, could you please follow up. >> >> Thanks, >> Alexei Regards, Alexey