Re: [patch 13/13] mm: memcontrol: rewrite uncharge API

From: Johannes Weiner
Date: Wed Jul 23 2014 - 17:03:00 EST


Hi Miklos,

On Wed, Jul 23, 2014 at 08:08:57PM +0200, Miklos Szeredi wrote:
> On Wed, Jul 23, 2014 at 5:06 PM, Johannes Weiner <hannes@xxxxxxxxxxx> wrote:
> > Can the new page be anything else than previous page cache?
>
> It could be an ordinary pipe buffer too. Stealable as well (see
> generic_pipe_buf_steal()).

Okay, they need charging, so we can't get rid of mem_cgroup_migrate()
in replace_page_cache(). With the fuse example mount you described I
can trigger the current code to blow up, so below is a fix to check if
the target page is already charged.

On an unrelated note, while playing around with the fuse example mount
and heavy swapping workloads I get the following in dmesg (changed
fuse_check_page() to use dump_page(), will send a patch later):

[ 298.771921] page:ffffea000468cb80 count:1 mapcount:0 mapping: (null) index:0x1e852f8
[ 298.780517] page flags: 0x5fffc000080029(locked|uptodate|lru|swapbacked)
[ 298.787385] page dumped because: fuse: trying to steal weird page
[ 298.793500] pc:ffff880215f232e0 pc->flags:7 pc->mem_cgroup:ffff880216c23000

[ 298.801031] page:ffffea0004662f00 count:1 mapcount:0 mapping: (null) index:0x1e85324
[ 298.809689] page flags: 0x5fffc000080029(locked|uptodate|lru|swapbacked)
[ 298.816615] page dumped because: fuse: trying to steal weird page
[ 298.822791] pc:ffff880215f18bc0 pc->flags:7 pc->mem_cgroup:ffff880216c23000

etc.

Somehow the page stealing ends up taking out anonymous pages, but it
must be a race condition as it happens rarely and irregularly.

---