From owner-freebsd-questions@FreeBSD.ORG Fri Aug 3 20:27:59 2007 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1770316A417 for ; Fri, 3 Aug 2007 20:27:59 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 1383C13C474 for ; Fri, 3 Aug 2007 20:27:59 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from rot26.obsecurity.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 9D0761A4D7E; Fri, 3 Aug 2007 13:27:22 -0700 (PDT) Received: by rot26.obsecurity.org (Postfix, from userid 1001) id 339F2BB43; Fri, 3 Aug 2007 16:27:58 -0400 (EDT) Date: Fri, 3 Aug 2007 16:27:58 -0400 From: Kris Kennaway To: Wojciech Puchar Message-ID: <20070803202757.GA68434@rot26.obsecurity.org> References: <20070803172639.F17414@wojtek.tensor.gdynia.pl> <20070803164621.GA65921@rot26.obsecurity.org> <20070803220027.C19191@wojtek.tensor.gdynia.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070803220027.C19191@wojtek.tensor.gdynia.pl> User-Agent: Mutt/1.4.2.3i Cc: freebsd-questions@freebsd.org, Kris Kennaway Subject: Re: parformance patch? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2007 20:27:59 -0000 On Fri, Aug 03, 2007 at 10:04:18PM +0200, Wojciech Puchar wrote: > >>-#define MAXPHYS (128 * 1024) /* max raw I/O transfer > >>size */ > >>+#define MAXPHYS (512 * 1024) /* max raw I/O transfer > >>size */ > >>both works for me and gives noticable speedup, when operating on big files > >>and when starting big apps or swapping. > > > >There are assumptions about the value of MAXPHYS all through the > >kernel. I doubt this patch works properly - it is something that > >should be fixed more completely though. > > > funny but THIS patch (MAXPHYS, not other) is working for me on 4 heavily > loaded servers for over a year with FreeBSD 6.2 Lucky you ;) Doesn't mean that parts of the kernel you're not using can handle it. > >>/* > >> * SWB_NPAGES must be a power of 2. It may be set to 1, 2, 4, 8, or 16 > >> * pages per allocation. We recommend you stick with the default of 8. > >> * The 16-page limit is due to the radix code (kern/subr_blist.c). > >> */ > >> > >>#ifndef MAX_PAGEOUT_CLUSTER > >>#define MAX_PAGEOUT_CLUSTER 16 > >>#endif > >> > >> > >> > >>can this be changed/fixed? 64-128 would be nicer... > > > >Why? i.e. what are the implications of this, good and bad? > > > > 16*4=64kbytes > > for modern disk drives 64 kbytes is transferred below 1 milisecond, while > seek takes 8-10ms by average. > > doing so small I/O is inefficient. something like 512kB (128 pages) looks > better. > > > patched vm_fault make pageins faster, but not pageout. disks often does > write caching clustering pageouts anyway, but probably not that efficient. This is pageout, not pagein. Probably the negative effect is that the when paging out the system does I/O in larger chunks, improving swap throughput but increasing delays for other applications. Kris