parformance patch?

[Kris Kennaway]

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