Date: Fri, 3 Aug 2007 22:04:18 +0200 (CEST) From: Wojciech Puchar <wojtek@wojtek.tensor.gdynia.pl> To: Kris Kennaway <kris@obsecurity.org> Cc: freebsd-questions@freebsd.org Subject: Re: parformance patch? Message-ID: <20070803220027.C19191@wojtek.tensor.gdynia.pl> In-Reply-To: <20070803164621.GA65921@rot26.obsecurity.org> References: <20070803172639.F17414@wojtek.tensor.gdynia.pl> <20070803164621.GA65921@rot26.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>> -#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 while vm patch is running on my notebook for 2 days only, ok for now but still testing. > >> other question (swap_pager.c): >> >> /* >> * 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070803220027.C19191>