From patchwork Thu Mar 6 09:05:46 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Chris Wilson X-Patchwork-Id: 3782211 Return-Path: X-Original-To: patchwork-intel-gfx@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id E031C9F35F for ; Thu, 6 Mar 2014 09:05:56 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 1580720203 for ; Thu, 6 Mar 2014 09:05:56 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by mail.kernel.org (Postfix) with ESMTP id 24D57201B6 for ; Thu, 6 Mar 2014 09:05:55 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id C0F69FABE4; Thu, 6 Mar 2014 01:05:51 -0800 (PST) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from fireflyinternet.com (mail.fireflyinternet.com [87.106.93.118]) by gabe.freedesktop.org (Postfix) with ESMTP id 8CBF0FABE4 for ; Thu, 6 Mar 2014 01:05:49 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=78.156.73.22; Received: from nuc-i3427.alporthouse.com (unverified [78.156.73.22]) by fireflyinternet.com (Firefly Internet (M1)) with ESMTP id 22309874-1500048 for multiple; Thu, 06 Mar 2014 09:06:11 +0000 Received: by nuc-i3427.alporthouse.com (sSMTP sendmail emulation); Thu, 06 Mar 2014 09:05:46 +0000 Date: Thu, 6 Mar 2014 09:05:46 +0000 From: Chris Wilson To: Hugh Dickins Message-ID: <20140306090546.GD15072@nuc-i3427.alporthouse.com> Mail-Followup-To: Chris Wilson , Hugh Dickins , intel-gfx@lists.freedesktop.org References: <1394019878-25979-1-git-send-email-chris@chris-wilson.co.uk> <1394019878-25979-2-git-send-email-chris@chris-wilson.co.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] [PATCH 1/5] shmemfs: Report ENOMEM for page allocation failures outside of tmpfs faults X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces@lists.freedesktop.org Errors-To: intel-gfx-bounces@lists.freedesktop.org X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Wed, Mar 05, 2014 at 07:14:49PM -0800, Hugh Dickins wrote: > On Wed, 5 Mar 2014, Chris Wilson wrote: > > > The intention of returning ENOSPC for a page allocation failure due to > > memory exhausstion in shmem_getpage_gfp() is purely "so that a failure > > on a sparse tmpfs mapping will give SIGBUS not OOM." However, for other > > callers, for example i915.ko, we want to distinguish the error message > > reported to userspace between ENOSPC (meaning that we were unable to fit > > the object/execbuffer into the aperture) and ENOMEM (meaning that we > > were unable to allocate pages for the object). > > > > Signed-off-by: Chris Wilson > > Cc: Hugh Dickins > > I'm not keen on this: perhaps because it looks like a hack of yours - > and draws attention to what might be thought a hack of mine ;) > > Nor am I thrilled by what was there before (we have three cases which > ought to be distinguished, but only ENOMEM and ENOSPC to distinguish > between them); but would rather it stay as is, than change what's > reported to the user after all these years. > > But I do see your point, and asking you to convert ENOSPC to ENOMEM > in all your drivers/gpu calls might be tiresome. > > I think we have a reasonable compromise: shmem_read_mapping_page_gfp() > is already the wrapper provided just for you guys, how about posting > a patch to map ENOSPC to ENOMEM there? > > (You're using the MS_KERNMOUNT, so won't hit a max_blocks limit.) Actually, I only need to the conversion along a single error path. So if you are happy that the only reason shmem_get_page() would report -ENOSPC would be for a hard memory failure, it seems permissible to simply fix it up in our driver: git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index f2efed9955bd..cfc4fcd90b6b 100644 Whether the other drivers (gma500, msm, omapdrm, udl, armada) care about the strict distinction between ENOSPC and ENOMEM, I do not know. Would it be possible for us to use sbinfo->max_blocks to reject large objects in drm_gem_object_init()? -Chris --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -2099,7 +2099,19 @@ err_pages: page_cache_release(sg_page_iter_page(&sg_iter)); sg_free_table(st); kfree(st); - return PTR_ERR(page); + + /* shmemfs first checks if there is enough memory to allocate the page + * and reports ENOSPC should there be insufficient, along with the usual + * ENOMEM for a genuine allocation failure. + * + * We use ENOSPC in our driver to mean that we have run out of GTT + * space and so want to translate the error from shmemfs back to our + * usual understanding of ENOMEM. + */ + if (PTR_ERR(page) == -ENOSPC) + return -ENOMEM; + else + return PTR_ERR(page); } /* Ensure that the associated pages are gathered from the backing storage