From owner-freebsd-fs@freebsd.org Sat Aug 8 11:37:58 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4C0B49B61DB for ; Sat, 8 Aug 2015 11:37:58 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 30881135E for ; Sat, 8 Aug 2015 11:37:58 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 2DB009B61DA; Sat, 8 Aug 2015 11:37:58 +0000 (UTC) Delivered-To: fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 147B49B61D9 for ; Sat, 8 Aug 2015 11:37:58 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AE697135B for ; Sat, 8 Aug 2015 11:37:57 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id t78Bbon1022106 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 8 Aug 2015 14:37:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua t78Bbon1022106 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id t78Bbo95022105; Sat, 8 Aug 2015 14:37:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 8 Aug 2015 14:37:50 +0300 From: Konstantin Belousov To: Willem Jan Withagen Cc: fs@freebsd.org Subject: Re: Using SSDs as swap Message-ID: <20150808113750.GC2072@kib.kiev.ua> References: <55C5D48E.6010605@digiware.nl> <20150808102900.GA2072@kib.kiev.ua> <55C5E34B.9010905@digiware.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55C5E34B.9010905@digiware.nl> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2015 11:37:58 -0000 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.