linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexei Budankov <abudankov@huawei.com>
To: "Bayduraev, Alexey V" <alexey.v.bayduraev@linux.intel.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>, <abudankov@huawei.com>
Subject: Re: [PATCH v2 1/3] Revert "perf session: Fix decompression of PERF_RECORD_COMPRESSED records"
Date: Wed, 2 Dec 2020 17:18:56 +0300	[thread overview]
Message-ID: <53805573-fa3e-21af-4df8-82a5b8cc7beb@huawei.com> (raw)
In-Reply-To: <545dfd5b-670a-a215-4484-29fe10b18517@linux.intel.com>


Hi Alexey. Please see below.

On 02.12.2020 17:04, Bayduraev, Alexey V wrote:
> 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.

Next time please avoid top posting and reply in line.
For this specific case it is right here just below my
previous answer.

Thanks,
Alexei


      reply	other threads:[~2020-12-02 14:20 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
2020-12-02 14:18                 ` Alexei Budankov [this message]

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=53805573-fa3e-21af-4df8-82a5b8cc7beb@huawei.com \
    --to=abudankov@huawei.com \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=alexey.v.bayduraev@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).