[lkml]   [2014]   [Feb]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] mm:prototype for the updated swapoff implementation
On 02/27/2014 07:33 PM, Hugh Dickins wrote:
> On Tue, 18 Feb 2014, Kelley Nielsen 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.
> You've chosen a good target, and I like the look of what you've done.
> But I'm afraid it will have to get uglier before it's ready, and I'm
> unsure whether your approach will prove to be a clear win or not.

I am more optimistic than you, because I have seen swapoff
on my Nehalem system proceed at under 1MB/s for several hours,
to clear maybe 3-4GB of stuff out of swap :)

>> 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.
> That's nice, but mostly it's the time spent that matters.
> I should explain why we've left the try_to_unuse() implementation as is
> for so many years: it's a matter of tradeoff between fast cpu and slow
> seeking disk.

> I'll be surprised if your approach does not improve swapoff from SSD
> (and brd and zram and zswap) very significantly; but the case to worry
> about is swapoff from hard disk. You are changing swapoff to use the
> cpu much more efficiently; but now that you no longer move linearly up
> the swap_map, you are making the disk head seek around very much more.

I suspect proper read-around of the swap area should take care of
IO patterns well enough. The quadratic nature of the current
try_to_unuse search can easily slow things down to comically low

All rights reversed.

 \ /
  Last update: 2014-02-28 21:01    [W:0.612 / U:0.432 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site