From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by gabe.freedesktop.org (Postfix) with ESMTPS id 2293A6E0AB for ; Tue, 11 May 2021 16:19:36 +0000 (UTC) Date: Tue, 11 May 2021 09:19:34 -0700 Message-ID: <871radw8dl.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" In-Reply-To: <20210511090000.1521342-1-maarten.lankhorst@linux.intel.com> References: <20210511090000.1521342-1-maarten.lankhorst@linux.intel.com> MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Subject: Re: [igt-dev] [PATCH i-g-t] i915: Handle the case where legacy mmap is not available List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: igt-dev-bounces@lists.freedesktop.org Sender: "igt-dev" To: Maarten Lankhorst Cc: igt-dev@lists.freedesktop.org List-ID: On Tue, 11 May 2021 02:00:00 -0700, Maarten Lankhorst wrote: > > We will remove support for the legacy mmap ioctl, so handle that > case without rewriting all tests. > > When the gem_mmap ioctl is not available, transparently fallback to > mmap_offset. Unless we've done something in the kernel, with this we should expect to see failures when object size approaches available system memory since as we know the mmap_offset page fault handler tries to pin the entire object which would fail for large objects. The old gem_mmap doesn't have this limitation. With pread/pwrite gone, the only option for large objects was to gem_mmap and read/write but appears that will now go away too. See e.g. https://patchwork.freedesktop.org/patch/426749/?series=88561&rev=3 _______________________________________________ igt-dev mailing list igt-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/igt-dev