From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 661A5C433F5 for ; Tue, 1 Mar 2022 22:24:42 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id B875E10E6F4; Tue, 1 Mar 2022 22:24:41 +0000 (UTC) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by gabe.freedesktop.org (Postfix) with ESMTPS id E357C10E6F4; Tue, 1 Mar 2022 22:24:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1646173480; x=1677709480; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=10FMhKUxTfR1RTdhGbvmv8TJy96SEiXZlwOjxz62GkU=; b=eAxWzL4swMB+L21vj41u9G4EA/YvGV+SsOSXPWiE1xMkhZ2ZPS0PPfuL ySmH+PZJYfjdCxY8hVlg/Y3XqEwR3NZ76tuKiyQivUBDrHOhTCsw/01zv i2GcpkuMEQMcrgYLX5DtTznDBys5OOtV3hh0uLlW5g6e2K4+PH6AujwIj Pm/TQjjaQsnzSQt5Myoa/4FKg4w+qQZyGB8c+2sHtzCymjlgfeBGZLyqY 0HFGn7lipxu2VkR68q/Z26rE5BUDWfs96Gi1DRgtti1wypQzaxMYtdPQT XkltT7ZfX3I04lab0z0PXK/4mrEXCwBPgXPruqubSTMsbzAo5x7EpOZPE Q==; X-IronPort-AV: E=McAfee;i="6200,9189,10273"; a="316470896" X-IronPort-AV: E=Sophos;i="5.90,146,1643702400"; d="scan'208";a="316470896" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Mar 2022 14:24:38 -0800 X-IronPort-AV: E=Sophos;i="5.90,146,1643702400"; d="scan'208";a="575872656" Received: from adixit-mobl1.amr.corp.intel.com (HELO adixit-arch.intel.com) ([10.209.13.76]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Mar 2022 14:24:38 -0800 Date: Tue, 01 Mar 2022 14:24:38 -0800 Message-ID: <87tuchfh09.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Matthew Auld In-Reply-To: <20220301110359.663637-1-matthew.auld@intel.com> References: <20220301110359.663637-1-matthew.auld@intel.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.2 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Subject: Re: [Intel-gfx] [PATCH i-g-t] tests/i915/gem_exec_params: check available memory earlier X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: igt-dev@lists.freedesktop.org, intel-gfx@lists.freedesktop.org Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Tue, 01 Mar 2022 03:03:59 -0800, Matthew Auld wrote: > > The shmem mmap and pwrite interfaces conveniently let us probe just a > few pages, without needing to populate the entire object. On discrete > and newer platforms the kernel has dropped support for both, leaving us > with MMAP_OFFSET, which will always populate the entire object, for now > at least. Luckily we can just move the batch creation to after checking > the available memory to ensure we don't hit -ENOMEM on such platforms. > > Also it seems that doing a massive allocation(filling much of system > memory) and then calling intel_purge_vm_caches() seems to take 40+ > seconds, like when calling intel_require_memory(). Hence switching the > ordering here should also help with that. > > For reference the larger-than-life test is just a simple regression test > to ensure that some very large batch buffer(greater than ~4G) can't > overflow the batch_len, causing all kinds of issues. See 57b2d834bf23 > ("drm/i915/gem: Support parsing of oversize batches"). I believe we tried this identical patch some time but don't remember why it was never merged. Maybe it was not helping or more likely we weren't sure it wouldn't break the test somehow (considering all the shmfs/swap stuff). But if we think it's ok to merge this and may actually resolve the -ENOMEM issue, this is: Reviewed-by: Ashutosh Dixit