linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Bayduraev, Alexey V" <alexey.v.bayduraev@linux.intel.com>
To: Alexei Budankov <abudankov@huawei.com>,
	Jiri Olsa <jolsa@redhat.com>, Petr Malat <oss@malat.biz>
Cc: linux-kernel@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Namhyung Kim <namhyung@kernel.org>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Kan Liang <kan.liang@linux.intel.com>
Subject: Re: [PATCH v2 1/3] Revert "perf session: Fix decompression of PERF_RECORD_COMPRESSED records"
Date: Wed, 2 Dec 2020 17:04:47 +0300	[thread overview]
Message-ID: <545dfd5b-670a-a215-4484-29fe10b18517@linux.intel.com> (raw)
In-Reply-To: <1ee1c9b6-516f-cee1-1b37-388fb5507cd3@huawei.com>

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

  reply	other threads:[~2020-12-02 14:06 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-24  9:59 [PATCH 1/3] Revert "perf session: Fix decompression of PERF_RECORD_COMPRESSED records" Petr Malat
2020-11-24  9:59 ` [PATCH 2/3] Revert "perf session: Avoid infinite loop when seeing invalid header.size" Petr Malat
2020-11-24  9:59 ` [PATCH 3/3] perf session: Avoid infinite loop if an event is truncated Petr Malat
2020-11-24 10:21   ` Petr Malat
2020-11-24 10:29 ` [PATCH v2 1/3] Revert "perf session: Fix decompression of PERF_RECORD_COMPRESSED records" Petr Malat
2020-11-24 10:29   ` [PATCH v2 2/3] Revert "perf session: Avoid infinite loop when seeing invalid header.size" Petr Malat
2020-11-24 10:29   ` [PATCH v2 3/3] perf session: Avoid infinite loop if an event is truncated Petr Malat
2020-11-24 14:36   ` [PATCH v2 1/3] Revert "perf session: Fix decompression of PERF_RECORD_COMPRESSED records" Jiri Olsa
2020-11-24 18:15     ` Petr Malat
2020-11-30 11:40       ` Petr Malat
2020-12-01 19:09         ` Jiri Olsa
2020-12-01 21:04           ` Alexei Budankov
2020-12-01 21:28             ` Alexei Budankov
2020-12-02 14:04               ` Bayduraev, Alexey V [this message]
2020-12-02 14:18                 ` Alexei Budankov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=545dfd5b-670a-a215-4484-29fe10b18517@linux.intel.com \
    --to=alexey.v.bayduraev@linux.intel.com \
    --cc=abudankov@huawei.com \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=jolsa@redhat.com \
    --cc=kan.liang@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=oss@malat.biz \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).