linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nigel Cunningham <ncunningham-lkml@crca.org.au>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
	kosaki.motohiro@jp.fujitsu.com, rjw@sisk.pl, riel@redhat.com,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 3/3][RFC] swsusp: shrink file cache first
Date: Sat, 07 Feb 2009 15:41:00 +1100	[thread overview]
Message-ID: <1233981660.12224.1.camel@nigel-laptop> (raw)
In-Reply-To: <20090206130009.99400d43.akpm@linux-foundation.org>

Hi.

On Fri, 2009-02-06 at 13:00 -0800, Andrew Morton wrote:
> On Fri, 6 Feb 2009 05:49:07 +0100
> Johannes Weiner <hannes@cmpxchg.org> wrote:
> 
> > > and, I think you should mesure performence result.
> > 
> > Yes, I'm still thinking about ideas how to quantify it properly.  I
> > have not yet found a reliable way to check for whether the working set
> > is intact besides seeing whether the resumed applications are
> > responsive right away or if they first have to swap in their pages
> > again.
> 
> Describing your subjective non-quantitative impressions would be better
> than nothing...
> 
> The patch bugs me.
> 
> The whole darn point behind the whole darn page reclaim is "reclaim the
> pages which we aren't likely to need soon".  There's nothing special
> about the swsusp code at all!  We want it to do exactly what page
> reclaim normally does, only faster.
> 
> So why do we need to write special hand-rolled code to implement
> something which we've already spent ten years writing?
> 
> hm?  And if this approach leads to less-than-optimum performance after
> resume then the fault lies with core page reclaim - it reclaimed the
> wrong pages!
> 
> That actually was my thinking when I first worked on
> shrink_all_memory() and it did turn out to be surprisingly hard to
> simply reuse the existing reclaim code for this application.  Things
> kept on going wrong.  IIRC this was because we were freeing pages as we
> were reclaiming, so the page reclaim logic kept on seeing all these
> free pages and kept on wanting to bale out.
> 
> Now, the simple and obvious fix to this is not to free the pages - just
> keep on allocating pages and storing them locally until we have
> "enough" memory.  Then when we're all done, dump them all straight onto
> to the freelists.
> 
> But for some reason which I do not recall, we couldn't do that.
> 
> It would be good to revisit all this.

It would be. It would be good, too, if 'we' could make it actually free
the number of pages it's asked for, too. At the moment, you generally
get something like 90% of what you ask for. Makes carefully calculating
how much you need to ask for a bit pointless :\

Nigel


  parent reply	other threads:[~2009-02-07  4:40 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-06  3:11 [PATCH 0/3] [PATCH 0/3] swsusp: shrink file cache first Johannes Weiner
2009-02-06  3:11 ` [PATCH 1/3] swsusp: clean up shrink_all_zones() Johannes Weiner
2009-02-06  3:20   ` KOSAKI Motohiro
2009-02-06  3:11 ` [PATCH 2/3] swsusp: dont fiddle with swappiness Johannes Weiner
2009-02-06  3:21   ` KOSAKI Motohiro
2009-02-06  3:11 ` [PATCH 3/3][RFC] swsusp: shrink file cache first Johannes Weiner
2009-02-06  3:39   ` KOSAKI Motohiro
2009-02-06  4:49     ` Johannes Weiner
2009-02-06  5:59       ` KOSAKI Motohiro
2009-02-06 12:24         ` Johannes Weiner
2009-02-06 13:35           ` MinChan Kim
2009-02-06 17:15             ` MinChan Kim
2009-02-06 23:37               ` Johannes Weiner
2009-02-09 19:43               ` [patch] vmscan: rename sc.may_swap to may_unmap Johannes Weiner
2009-02-09 23:02                 ` MinChan Kim
2009-02-10 10:00                   ` KOSAKI Motohiro
2009-03-27  6:19                 ` [PATCH] vmscan: memcg needs may_swap (Re: [patch] vmscan: rename sc.may_swap to may_unmap) Daisuke Nishimura
2009-03-27  6:30                   ` KAMEZAWA Hiroyuki
2009-03-29 23:45                     ` KOSAKI Motohiro
2009-03-31  0:18                       ` Daisuke Nishimura
2009-03-31  1:26                       ` Minchan Kim
2009-03-31  1:42                         ` KAMEZAWA Hiroyuki
2009-03-31  1:48                           ` KOSAKI Motohiro
2009-04-01  4:09                             ` Johannes Weiner
2009-04-01  5:08                               ` Daisuke Nishimura
2009-04-01  9:04                               ` KAMEZAWA Hiroyuki
2009-04-01  9:11                                 ` KOSAKI Motohiro
2009-04-01  9:49                                 ` Johannes Weiner
2009-04-01  9:55                                   ` KOSAKI Motohiro
2009-04-01 16:03                                     ` Johannes Weiner
2009-03-31  1:52                         ` Daisuke Nishimura
2009-02-06 21:00       ` [PATCH 3/3][RFC] swsusp: shrink file cache first Andrew Morton
2009-02-06 23:27         ` Johannes Weiner
2009-02-07 17:23           ` Rafael J. Wysocki
2009-02-08 20:56             ` Johannes Weiner
2009-02-07  4:41         ` Nigel Cunningham [this message]
2009-02-07 16:51         ` KOSAKI Motohiro
2009-02-07 21:20           ` Nigel Cunningham
2009-02-27 13:27         ` Pavel Machek
2009-03-01 10:37           ` KOSAKI Motohiro
2009-02-06  8:03   ` MinChan Kim
2009-02-06 10:06     ` MinChan Kim
2009-02-06 11:50       ` Johannes Weiner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1233981660.12224.1.camel@nigel-laptop \
    --to=ncunningham-lkml@crca.org.au \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=riel@redhat.com \
    --cc=rjw@sisk.pl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).