Re: [RFC][PATCH 5/5] (experimental) chase and free cache only swap
From: Johannes Weiner
Date: Tue May 26 2009 - 22:07:54 EST
On Wed, May 27, 2009 at 10:31:07AM +0900, KAMEZAWA Hiroyuki wrote:
> On Wed, 27 May 2009 03:26:58 +0200
> Johannes Weiner <hannes@xxxxxxxxxxx> wrote:
>
> > On Wed, May 27, 2009 at 09:08:13AM +0900, KAMEZAWA Hiroyuki wrote:
> > > On Tue, 26 May 2009 20:14:00 +0200
> > > Johannes Weiner <hannes@xxxxxxxxxxx> wrote:
> > >
> > > > On Tue, May 26, 2009 at 12:18:34PM +0900, KAMEZAWA Hiroyuki wrote:
> > > > >
> > > > > From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx>
> > > > >
> > > > > Just a trial/example patch.
> > > > > I'd like to consider more. Better implementation idea is welcome.
> > > > >
> > > > > When the system does swap-in/swap-out repeatedly, there are
> > > > > cache-only swaps in general.
> > > > > Typically,
> > > > > - swapped out in past but on memory now while vm_swap_full() returns true
> > > > > pages are cache-only swaps. (swap_map has no references.)
> > > > >
> > > > > This cache-only swaps can be an obstacles for smooth page reclaiming.
> > > > > Current implemantation is very naive, just scan & free.
> > > >
> > > > I think we can just remove that vm_swap_full() check in do_swap_page()
> > > > and try to remove the page from swap cache unconditionally.
> > > >
> > > I'm not sure why reclaim swap entry only at write fault.
> >
> > How do you come to that conclusion? Do you mean the current code does
> > that?
> yes.
>
> 2474 pte = mk_pte(page, vma->vm_page_prot);
> 2475 if (write_access && reuse_swap_page(page)) {
> 2476 pte = maybe_mkwrite(pte_mkdirty(pte), vma);
> 2477 write_access = 0;
> 2478 }
Ahh. But further down after installing the PTE, it does
swap_free(entry);
if (vm_swap_full() || (vma->vm_flags & VM_LOCKED) || PageMlocked(page))
try_to_free_swap(page);
unlock_page(page);
You are right, it tries to reuse the page and free the swap slot for
writes, but later it removes the swap reference from the pte and then
tries to free the slot again, also for reads.
My suggestion was to remove these checks in the second attempt and
just try regardless of swap usage or mlock. I just sent out a patch
that does that.
--
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/