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
