From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by gabe.freedesktop.org (Postfix) with ESMTPS id 7A9B989C99 for ; Mon, 27 Jul 2020 07:31:47 +0000 (UTC) References: <20200721015717.46279-1-umesh.nerlige.ramappa@intel.com> <20200721015717.46279-2-umesh.nerlige.ramappa@intel.com> <1b566afd-4806-cad9-1a55-e54bf3fdb1d9@intel.com> <20200724233319.GA45897@orsosgc001.amr.corp.intel.com> From: Lionel Landwerlin Message-ID: Date: Mon, 27 Jul 2020 10:31:45 +0300 MIME-Version: 1.0 In-Reply-To: <20200724233319.GA45897@orsosgc001.amr.corp.intel.com> Content-Language: en-US Subject: Re: [igt-dev] [PATCH 2/2] i915/perf: Sanity check reports in mapped OA buffer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0265589332==" Errors-To: igt-dev-bounces@lists.freedesktop.org Sender: "igt-dev" To: Umesh Nerlige Ramappa Cc: igt-dev@lists.freedesktop.org List-ID: This is a multi-part message in MIME format. --===============0265589332== Content-Type: multipart/alternative; boundary="------------7D68D3660B1D210E9312ADDF" Content-Language: en-US This is a multi-part message in MIME format. --------------7D68D3660B1D210E9312ADDF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 25/07/2020 02:33, Umesh Nerlige Ramappa wrote: >> >> 16Mb * 256 = 4Gb >> >> That way you verify that we're not leaking GGTT space when closing >> the perf fd. >> >> You might want to tweak the noa_wait sysfs value before/after the loop. >> >> This might also only work on !32bits machines with enough memory... >> > > Looks like calling close() in the above sequence will not result in a > call to i915_perf_release (because mmap holds a reference to the file). > Based on the latest patch series in the mailing list, if you see > something we can add, please let me know. Note that we block mremap of > an mmap-ped address by setting VM_DONTEXPAND in i915 perf mmap > implementation. > > Thanks, > Umesh Oh thanks for reminding me :) Since mmap holds a ref that means nobody will be able to open the stream once more until munmap is called. So there won't be any GGTT space leakage and it's all good. Forget my request then. Thanks! -Lionel --------------7D68D3660B1D210E9312ADDF Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit
On 25/07/2020 02:33, Umesh Nerlige Ramappa wrote:

16Mb * 256 = 4Gb

That way you verify that we're not leaking GGTT space when closing the perf fd.

You might want to tweak the noa_wait sysfs value before/after the loop.

This might also only work on !32bits machines with enough memory...


Looks like calling close() in the above sequence will not result in a call to i915_perf_release (because mmap holds a reference to the file). 
Based on the latest patch series in the mailing list, if you see something we can add, please let me know. Note that we block mremap of an mmap-ped address by setting VM_DONTEXPAND in i915 perf mmap implementation.

Thanks,
Umesh

Oh thanks for reminding me :)

Since mmap holds a ref that means nobody will be able to open the stream once more until munmap is called.

So there won't be any GGTT space leakage and it's all good.


Forget my request then.

Thanks!


-Lionel

--------------7D68D3660B1D210E9312ADDF-- --===============0265589332== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ igt-dev mailing list igt-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/igt-dev --===============0265589332==--