On Wed, 3 Nov 2010 10:26:11 -0500, "Jason Detring" <[email protected]> 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 <[email protected]> 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 _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
