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 _______________________________________________ firstname.lastname@example.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"