Date: Fri, 3 Aug 2007 16:27:58 -0400 From: Kris Kennaway <kris@obsecurity.org> To: Wojciech Puchar <wojtek@wojtek.tensor.gdynia.pl> Cc: freebsd-questions@freebsd.org, Kris Kennaway <kris@obsecurity.org> Subject: Re: parformance patch? Message-ID: <20070803202757.GA68434@rot26.obsecurity.org> In-Reply-To: <20070803220027.C19191@wojtek.tensor.gdynia.pl> References: <20070803172639.F17414@wojtek.tensor.gdynia.pl> <20070803164621.GA65921@rot26.obsecurity.org> <20070803220027.C19191@wojtek.tensor.gdynia.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070803202757.GA68434>