From: Josh Triplett <josh@joshtriplett.org>
To: Rik van Riel <riel@surriel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Kelley Nielsen <kelleynnn@gmail.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
opw-kernel@googlegroups.com, jamieliu@google.com,
sjenning@linux.vnet.ibm.com, Hugh Dickins <hughd@google.com>
Subject: Re: [OPW kernel] Re: [RFC] mm:prototype for the updated swapoff implementation
Date: Wed, 19 Feb 2014 15:08:09 -0800 [thread overview]
Message-ID: <20140219230809.GA8221@jtriplet-mobl1> (raw)
In-Reply-To: <530524A3.6090700@surriel.com>
On Wed, Feb 19, 2014 at 04:39:47PM -0500, Rik van Riel wrote:
> On 02/19/2014 04:27 PM, Andrew Morton wrote:
> > On Tue, 18 Feb 2014 16:35:22 -0800 Kelley Nielsen <kelleynnn@gmail.com> wrote:
> >
> >> The function try_to_unuse() is of quadratic complexity, with a lot of
> >> wasted effort. It unuses swap entries one by one, potentially iterating
> >> over all the page tables for all the processes in the system for each
> >> one.
> >>
> >> This new proposed implementation of try_to_unuse simplifies its
> >> complexity to linear. It iterates over the system's mms once, unusing
> >> all the affected entries as it walks each set of page tables. It also
> >> makes similar changes to shmem_unuse.
> >>
> >> Improvement
> >>
> >> swapoff was called on a swap partition containing about 50M of data,
> >> and calls to the function unuse_pte_range were counted.
> >>
> >> Present implementation....about 22.5M calls.
> >> Prototype.................about 7.0K calls.
> >
> > Do you have situations in which swapoff is taking an unacceptable
> > amount of time? If so, please update the changelog to provide full
> > details on this, with before-and-after timing measurements.
>
> I have seen plenty of that. With just a few GB in swap space in
> use, on a system with 24GB of RAM, and about a dozen GB in use
> by various processes, I have seen swapoff take several hours of
> CPU time.
And it's clear what the lower bound on swapoff should be: current amount
of swap in use, divided by maximum disk write speed. We're definitely
not to *that* point yet; this ought to get us a lot closer.
- Josh Triplett
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Josh Triplett <josh@joshtriplett.org>
To: Rik van Riel <riel@surriel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Kelley Nielsen <kelleynnn@gmail.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
opw-kernel@googlegroups.com, jamieliu@google.com,
sjenning@linux.vnet.ibm.com, Hugh Dickins <hughd@google.com>
Subject: Re: [OPW kernel] Re: [RFC] mm:prototype for the updated swapoff implementation
Date: Wed, 19 Feb 2014 15:08:09 -0800 [thread overview]
Message-ID: <20140219230809.GA8221@jtriplet-mobl1> (raw)
In-Reply-To: <530524A3.6090700@surriel.com>
On Wed, Feb 19, 2014 at 04:39:47PM -0500, Rik van Riel wrote:
> On 02/19/2014 04:27 PM, Andrew Morton wrote:
> > On Tue, 18 Feb 2014 16:35:22 -0800 Kelley Nielsen <kelleynnn@gmail.com> wrote:
> >
> >> The function try_to_unuse() is of quadratic complexity, with a lot of
> >> wasted effort. It unuses swap entries one by one, potentially iterating
> >> over all the page tables for all the processes in the system for each
> >> one.
> >>
> >> This new proposed implementation of try_to_unuse simplifies its
> >> complexity to linear. It iterates over the system's mms once, unusing
> >> all the affected entries as it walks each set of page tables. It also
> >> makes similar changes to shmem_unuse.
> >>
> >> Improvement
> >>
> >> swapoff was called on a swap partition containing about 50M of data,
> >> and calls to the function unuse_pte_range were counted.
> >>
> >> Present implementation....about 22.5M calls.
> >> Prototype.................about 7.0K calls.
> >
> > Do you have situations in which swapoff is taking an unacceptable
> > amount of time? If so, please update the changelog to provide full
> > details on this, with before-and-after timing measurements.
>
> I have seen plenty of that. With just a few GB in swap space in
> use, on a system with 24GB of RAM, and about a dozen GB in use
> by various processes, I have seen swapoff take several hours of
> CPU time.
And it's clear what the lower bound on swapoff should be: current amount
of swap in use, divided by maximum disk write speed. We're definitely
not to *that* point yet; this ought to get us a lot closer.
- Josh Triplett
next prev parent reply other threads:[~2014-02-19 23:08 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-19 0:35 [RFC] mm:prototype for the updated swapoff implementation Kelley Nielsen
2014-02-19 0:35 ` Kelley Nielsen
2014-02-19 21:27 ` Andrew Morton
2014-02-19 21:27 ` Andrew Morton
2014-02-19 21:39 ` Rik van Riel
2014-02-19 21:39 ` Rik van Riel
2014-02-19 23:08 ` Josh Triplett [this message]
2014-02-19 23:08 ` [OPW kernel] " Josh Triplett
2014-02-19 23:42 ` One Thousand Gnomes
2014-02-19 23:42 ` One Thousand Gnomes
2014-02-25 20:14 ` Rik van Riel
2014-02-25 20:14 ` Rik van Riel
2014-02-28 0:33 ` Hugh Dickins
2014-02-28 0:33 ` Hugh Dickins
2014-02-28 18:07 ` Rik van Riel
2014-02-28 18:07 ` Rik van Riel
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=20140219230809.GA8221@jtriplet-mobl1 \
--to=josh@joshtriplett.org \
--cc=akpm@linux-foundation.org \
--cc=hughd@google.com \
--cc=jamieliu@google.com \
--cc=kelleynnn@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=opw-kernel@googlegroups.com \
--cc=riel@surriel.com \
--cc=sjenning@linux.vnet.ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.