From owner-freebsd-performance@FreeBSD.ORG Mon May 5 04:05:02 2003 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A7B5937B401 for ; Mon, 5 May 2003 04:05:02 -0700 (PDT) Received: from mx02.egartech.com (aloha.egartech.com [62.118.81.133]) by mx1.FreeBSD.org (Postfix) with SMTP id CE82543F3F for ; Mon, 5 May 2003 04:05:00 -0700 (PDT) (envelope-from temik@egartech.com) Received: (qmail 42028 invoked by uid 85); 5 May 2003 11:04:55 -0000 Received: from temik@egartech.com by mx02.egartech.com with qmail-scanner-1.03 (. Clean. Processed in 0.349709 secs); 05 May 2003 11:04:55 -0000 Received: from unknown (HELO turtle.egar.egartech.com) (192.168.8.4) by 0 with SMTP; 5 May 2003 11:04:54 -0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Mon, 5 May 2003 15:04:57 +0400 Message-ID: <5235EF9BAE6B7F4CB3735789EEF73B29B06A69@turtle.egar.egartech.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: freebsd-performance Digest, Vol 3, Issue 1 Thread-Index: AcMQRmMUFjTxtDgzRZGpJ7FHQ0DSRgCr08uw From: "Artem Tepponen" To: "Terry Lambert" cc: freebsd-performance@freebsd.org Subject: RE: freebsd-performance Digest, Vol 3, Issue 1 X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2003 11:05:03 -0000 > Too bad it's not supported, and too bad that, if it was, the > overhead would be too high because there's not VOP to get the > FS block offsets, so you would have to go trouh the FS code to > swap, and it would be much, much slower. Btw, do you have any fresh numbers on hand that can support this = statement? Naive approach whould be comparing CPU time taken and disk latencies that differ by an order of magnitude and conclude that few microseconds eaten by CPU would go unnoticed compared with milliseconds taken by = disk. Artem