Date: Fri, 3 Aug 2007 12:46:22 -0400 From: Kris Kennaway <kris@obsecurity.org> To: Wojciech Puchar <wojtek@wojtek.tensor.gdynia.pl> Cc: freebsd-questions@freebsd.org Subject: Re: parformance patch? Message-ID: <20070803164621.GA65921@rot26.obsecurity.org> In-Reply-To: <20070803172639.F17414@wojtek.tensor.gdynia.pl> References: <20070803172639.F17414@wojtek.tensor.gdynia.pl>
index | next in thread | previous in thread | raw e-mail
On Fri, Aug 03, 2007 at 05:26:49PM +0200, Wojciech Puchar wrote:
> is anything wrong in this?
>
> --- vm_fault.c.orig Fri Aug 3 15:01:27 2007
> +++ vm_fault.c Thu Aug 2 15:56:17 2007
> @@ -113,8 +113,8 @@
> static int vm_fault_additional_pages(vm_page_t, int, int, vm_page_t *, int
> *);
> static void vm_fault_prefault(pmap_t, vm_offset_t, vm_map_entry_t);
>
> -#define VM_FAULT_READ_AHEAD 8
> -#define VM_FAULT_READ_BEHIND 7
> +#define VM_FAULT_READ_AHEAD 64
> +#define VM_FAULT_READ_BEHIND 63
> #define VM_FAULT_READ (VM_FAULT_READ_AHEAD+VM_FAULT_READ_BEHIND+1)
>
> struct faultstate {
>
>
> and
>
> --- param.h.orig Fri Aug 3 15:02:37 2007
> +++ param.h Wed Jul 11 11:46:24 2007
> @@ -125,7 +125,7 @@
> #define DFLTPHYS (64 * 1024) /* default max raw I/O transfer
> size */
> #endif
> #ifndef MAXPHYS
> -#define MAXPHYS (128 * 1024) /* max raw I/O transfer
> size */
> +#define MAXPHYS (512 * 1024) /* max raw I/O transfer
> size */
> #endif
> #ifndef MAXDUMPPGS
> #define MAXDUMPPGS (DFLTPHYS/PAGE_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.
> 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?
Kris
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070803164621.GA65921>