All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rik van Riel <riel@surriel.com>
To: Andrew Morton <akpm@linux-foundation.org>,
	Kelley Nielsen <kelleynnn@gmail.com>
Cc: 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: [RFC] mm:prototype for the updated swapoff implementation
Date: Wed, 19 Feb 2014 16:39:47 -0500	[thread overview]
Message-ID: <530524A3.6090700@surriel.com> (raw)
In-Reply-To: <20140219132757.58b61f07bad914b3848275e9@linux-foundation.org>

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.

-- 
All rights reversed.

--
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: Rik van Riel <riel@surriel.com>
To: Andrew Morton <akpm@linux-foundation.org>,
	Kelley Nielsen <kelleynnn@gmail.com>
Cc: 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: [RFC] mm:prototype for the updated swapoff implementation
Date: Wed, 19 Feb 2014 16:39:47 -0500	[thread overview]
Message-ID: <530524A3.6090700@surriel.com> (raw)
In-Reply-To: <20140219132757.58b61f07bad914b3848275e9@linux-foundation.org>

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.

-- 
All rights reversed.

  reply	other threads:[~2014-02-19 21:39 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 [this message]
2014-02-19 21:39     ` Rik van Riel
2014-02-19 23:08     ` [OPW kernel] " Josh Triplett
2014-02-19 23:08       ` 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=530524A3.6090700@surriel.com \
    --to=riel@surriel.com \
    --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=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.