Re: [PATCH 0/3] make mapped executable pages the first classcitizen

[Jesse Barnes]

On Sat, 4 Jul 2009 09:27:54 +0800
Roger WANG <roger.wang@xxxxxxxxx> wrote:

> Hello Jesse,
> 
> On Sat, 2009-06-20 at 00:43 +0800 Jesse Barnes wrote:
> > On Fri, 19 Jun 2009 17:32:24 +0800
> > Wu Fengguang <fengguang.wu@xxxxxxxxx> wrote:
> > 
> > > On Fri, Jun 19, 2009 at 05:04:49PM +0800, Peter Zijlstra wrote:
> > > > On Fri, 2009-06-19 at 17:00 +0800, Wu, Fengguang wrote:
> > > > > [add CC]
> > > > > 
> > > > > This OOM case looks like the same bug encountered by David
> > > > > Howells.
> > > > > 
> > > > > > Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426766]
> > > > > > Active_anon:290797 active_file:28 inactive_anon:97034 Jun 18
> > > > > > 07:44:53 jbarnes-g45 kernel: [64377.426767]
> > > > > > inactive_file:61 unevictable:11322 dirty:0 writeback:0
> > > > > > unstable:0 Jun 18 07:44:53 jbarnes-g45 kernel:
> > > > > > [64377.426768]  free:3341 slab:13776 mapped:5880
> > > > > > pagetables:6851 bounce:0
> > > > > 
> > > > > active/inactive_anon pages take up 4/5 memory.  Are you using
> > > > > TMPFS a lot?
> > > > 
> > > > I suspect its his GEM thingy ;-)
> > > 
> > > Very likely - GEM allocates drm objects from the internal tmpfs,
> > > and libdrm_intel seems to never free drm objects from its cache.
> > 
> > Yeah, a good chunk of that is GEM objects.  I generally haven't seen
> > OOMs due to excessive GEM allocation though, until recently.  We've
> > got some patches queued up to manage the object cache better
> > (actually free pages when we don't need them!), so that should help.
> 
> Could you please point me to those patches so I can try them here? I
> have to kill my X once per day.

They're all upstream now; I've been running 2.6.31ish plus the latest
libdrm, Mesa and xf86-video-intel for a week or so and things are much
better (using the Ubuntu xorg edgers repo).

-- 
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/