From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Wilson Subject: Re: Memory leak in drm/i915? Date: Wed, 03 Nov 2010 16:02:26 +0000 Message-ID: <849307$a86oqb@azsmga001.ch.intel.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mga14.intel.com (mga14.intel.com [143.182.124.37]) by gabe.freedesktop.org (Postfix) with ESMTP id 1D2329E81C for ; Wed, 3 Nov 2010 09:02:30 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Jason Detring , intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Wed, 3 Nov 2010 10:26:11 -0500, "Jason Detring" wrote: > The problem observed is that performing this switch seems to grow system > cache usage by about 1.5 to 2 MB per iteration. This is unbounded, and > will fill both free memory and swap in the course of a few hours when > running our app in its demonstration cycle. At this point, the system > becomes unresponsive, eventually dumping the user to a text-mode kernel > panic message. Killing the app before the hang causes the system cache > and swap to be cleared on an intel-drm-next kernel, but not in the -rc3 > kernel (see software stacks later in this message). This suggests that the leak is connected with: commit 31dfbc93923c0aaa0440b809f80ff2830c6a531a Author: Chris Wilson Date: Mon Sep 27 21:28:30 2010 +0100 drm: Prune GEM vma entries Hook the GEM vm open/close ops into the generic drm vm open/close so that the private vma entries are created and destroy appropriately. Fixes the leak of the drm_vma_entries during the lifetime of the filp. Can you monitor /sys/debug/dri/0/i915_gem_objects and /proc/slabinfo and see where the memory is going? -Chris -- Chris Wilson, Intel Open Source Technology Centre