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
