Using SSDs as swap

[Konstantin Belousov]

On Sat, Aug 08, 2015 at 01:08:59PM +0200, Willem Jan Withagen wrote:
> On 8-8-2015 12:29, Konstantin Belousov wrote:
> > On Sat, Aug 08, 2015 at 12:06:06PM +0200, Willem Jan Withagen wrote:
> 
> >> 2) Does the SSD "suffer" unneeded from swapping on it?
> > Depends on your swapping activity, but yes, I believe that intense swapping
> > would wear SSD in the short time.
> 
> Would it be more intense than being beaten to death as a ARC cache??
No idea.  Ask somebody who understands how ARC works.

Swap is used for pageouts, and typical pageout involves the page and
some amount of pages surrounding it in the vm object' queue.  Defaults
are 32 pages as the maximum clustered pageout size, but I believe that
it is typically cannot be achieved, I would expect that often the
very minimalistic i/o requests are blasted. It might be better if the
dirty mappings are promoted to superpages, but I think that the promotion
is not likely to happen if your machine already started swapping.

Anyway, I do not posses a statistic for the pageout patters on the
real workloads. With the current state of hardware, it is much more
reasonable to buy enough RAM, which would give you two orders of
magnitude of the speedup, than to target swap subsystem optimization to
provide you e.g. 10-20% improvements comparing with the current state of
the code.

> 
> If I look at most of my systems I try to prevent them even using really
> swap since that usually kills performance big time...
> So things get swapped out under pressure, but rarely get swapped back
> in, because the LRU properties of that part of the application minimise
> that chance of things getting paged back in.
> 
> So the number of times that swap actually gets used is rather seldom.
> 
> In writting swap, how are the allocations made where things are swapped.
> Do things always end up in a lineair order on swap writting things as
> close to the start as slots in swap allow it. SSD would profit from it
> being sort of a circular buffer...
> (Guess I have to try and understand the swap code.... )
The swap block allocator is in kern/subr_blist.c.  It is a radix tree
search algorithm which looks for the contig range of free swap blocks
of the given size.  There are no any provisions for providing streaming
write behaviour (and it would be unnatural for the pageouts to have
this behaviour), I do not think that it would exhibit such behaviour
accidentally.