for symtom 1 desribed in commet #43(In reply to comment #33)
> To summarize:
> There seems two symptoms:
> 1. systems memories used by graphics driver will keep growing for a few times
> of resize operation, then drops dramatically, then grow again, and drops again
> ... If resize many times in very short time, it will consume all system memory
> and get X not resposible.
> 2. serious memory leak with composite, which will make graphics driver
> comsuming all system memory.
> on my Q35, I see neither of them
> on G45 and GM45, I see <1>, disable buffer reuse doesn't help here. it's
> desribed in comment #31
> on aspire one, I see <2>, disable buffer reuse doesn't help here. it's desribed
> in comment #32
> 

For the symptom  <1>, it seems it's the result of 965 state cache. 
I have tracked it with valgrind (with VALGRIND_PRINTF_BACKTRACE), following is one of the buffer object I checked, you can see buffer object 474 is allocated when a window is created, and this buffer object is deleted much later in brw_clear_cache

**6022** shuang 443 alloc: handle=474, size=256 KB
==6022==    at 0x5511171: VALGRIND_PRINTF_BACKTRACE (valgrind.h:3695)
==6022==    by 0x5511CF8: drm_intel_gem_bo_alloc_internal (intel_bufmgr_gem.c:437)
==6022==    by 0x550D473: drm_intel_bo_alloc_for_render (intel_bufmgr.c:58)
==6022==    by 0x52978AE: intel_region_alloc (intel_regions.c:173)
==6022==    by 0x52968A1: intel_miptree_create (intel_mipmap_tree.c:122)
==6022==    by 0x52B761B: intelTexImage (intel_tex_image.c:132)
==6022==    by 0x52B80CD: intelTexImage2D (intel_tex_image.c:587)
==6022==    by 0x5370B19: _mesa_TexImage2D (teximage.c:2676)
==6022==    by 0x45A021D: (within /usr/lib/tmp/libclutter-glx-0.9.so.0.903.0)
==6022==    by 0x45A04E8: cogl_texture_new_from_data (in /usr/lib/tmp/libclutter-glx-0.9.so.0.903.0)
==6022==    by 0x80A8F2F: (within /usr/bin/metacity)
==6022==    by 0x80A9112: (within /usr/bin/metacity)

**6022** shuang 6130 delete: handle=474, size=256 KB
==6022==    at 0x5511171: VALGRIND_PRINTF_BACKTRACE (valgrind.h:3695)
==6022==    by 0x551131E: drm_intel_gem_bo_unreference_locked (intel_bufmgr_gem.c:573)
==6022==    by 0x55112AD: drm_intel_gem_bo_unreference_locked (intel_bufmgr_gem.c:582)
==6022==    by 0x55112AD: drm_intel_gem_bo_unreference_locked (intel_bufmgr_gem.c:582)
==6022==    by 0x5511791: drm_intel_gem_bo_unreference (intel_bufmgr_gem.c:621)
==6022==    by 0x550D4B5: drm_intel_bo_unreference (intel_bufmgr.c:73)
==6022==    by 0x52D0B2A: brw_clear_cache (brw_state_cache.c:501)
==6022==    by 0x52D8C8C: brw_note_unlock (brw_vtbl.c:184)
==6022==    by 0x528C43B: UNLOCK_HARDWARE (intel_context.c:1078)
==6022==    by 0x52C58EA: brw_draw_prims (brw_draw.c:417)
==6022==    by 0x538E59B: vbo_exec_DrawRangeElements (vbo_exec_array.c:435)
==6022==    by 0x5382EB9: neutral_DrawRangeElements (vtxfmt_tmp.h:343)

If I reduced the limit of cached items, this symptom will disappear:

diff --git a/src/mesa/drivers/dri/i965/brw_state_cache.c b/src/mesa/drivers/dri/i965/brw_state_cache.c
index e40d7a0..0afb7af 100644
--- a/src/mesa/drivers/dri/i965/brw_state_cache.c
+++ b/src/mesa/drivers/dri/i965/brw_state_cache.c
@@ -527,10 +527,10 @@ brw_state_cache_check_size(struct brw_context *brw)
    /* un-tuned guess.  We've got around 20 state objects for a total of around
     * 32k, so 1000 of them is around 1.5MB.
     */
-   if (brw->cache.n_items > 1000)
+   if (brw->cache.n_items > 100)
       brw_clear_cache(brw, &brw->cache);

-   if (brw->surface_cache.n_items > 1000)
+   if (brw->surface_cache.n_items > 100)
       brw_clear_cache(brw, &brw->surface_cache);
 }