Re: parformance patch?
On Sat, Aug 04, 2007 at 09:40:14AM +0200, Wojciech Puchar wrote: > >>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. > > well - it exactly mean that it can :) I know for a fact that MAXPHYS cannot safely just be increased without other work, so if you are interested in working on this you should study more carefully how it is used directly and indirectly by other parts of the kernel. > >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. > > actually i tested changing it to 64 it was positive improvement, but after > shutting down kernel crashed. Did you measure interactivity and other aspects of performance during pageout? Kris ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: parformance patch?
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. well - it exactly mean that it can :) 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. actually i tested changing it to 64 it was positive improvement, but after shutting down kernel crashed. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: parformance patch?
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 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: parformance patch?
-#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. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: parformance patch?
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.origFri 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
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
parformance patch?
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.origFri 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.
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...
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
