From: Andrew Morton <akpm@linux-foundation.org>
To: Minchan Kim <minchan@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Mel Gorman <mgorman@suse.de>, Rik van Riel <riel@redhat.com>,
Hugh Dickins <hughd@google.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@suse.cz>
Subject: Re: [PATCH v3 0/3] free reclaimed pages by paging out instantly
Date: Mon, 7 Jul 2014 12:13:46 -0700 [thread overview]
Message-ID: <20140707121346.1487c20e2a9365325e3a81a6@linux-foundation.org> (raw)
In-Reply-To: <20140703005949.GC21751@bbox>
On Thu, 3 Jul 2014 09:59:49 +0900 Minchan Kim <minchan@kernel.org> wrote:
> > > Most of field in vmstat are not changed too much but things I can notice
> > > is allocstall and pgrotated. We could save allocstall(ie, direct relcaim)
> > > and pgrotated very much.
> > >
> > > Welcome testing, review and any feedback!
> >
> > Well, it will worsen IRQ latencies and it's all more code for us to
> > maintain. I think I'd like to see a better story about the end-user
> > benefits before proceeding.
>
> The motivation was from per-process reclaim(which was internal feature
> yet and and I will repost it soon).
> It's a feature for us to manage memory from platform so that we could
> avoid reclaim.
>
> Anyway, userspace expect they could see increased free pages in vmstat
> after they have done per-process reclaim so the logic of userspace
> will control their next action depending on the number of current
> free page but it doesn't work with existing rotation logic, expecially
> anon swap write pages.
>
> When I posted this patchset firstly, Rik was positive and I thought
> this feature is useful for everyone as well as per-process reclaim
> and don't want to make noise this patchset with perpcoess reclaim.
>
> https://lkml.org/lkml/2013/5/12/174
> https://lkml.org/lkml/2013/5/14/484
>
> Could you tell me what should I do to proceed?
Quantify the gains, quantify the losses then demonstrate that the
benefits of the gains exceeds the cost of the losses plus the cost of
ongoing maintenance!
prev parent reply other threads:[~2014-07-07 19:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-02 0:13 Minchan Kim
2014-07-02 0:13 ` [PATCH v3 1/3] mm: Don't hide spin_lock in swap_info_get internal Minchan Kim
2014-07-02 0:13 ` [PATCH v3 2/3] mm: Introduce atomic_remove_mapping Minchan Kim
2014-07-02 0:13 ` [PATCH v3 3/3] mm: Free reclaimed pages indepdent of next reclaim Minchan Kim
2014-07-02 20:42 ` [PATCH v3 0/3] free reclaimed pages by paging out instantly Andrew Morton
2014-07-03 0:59 ` Minchan Kim
2014-07-07 19:13 ` Andrew Morton [this message]
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=20140707121346.1487c20e2a9365325e3a81a6@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@suse.cz \
--cc=minchan@kernel.org \
--cc=riel@redhat.com \
/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
all inboxes | Powered by JetHome®