From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 25 16:32:25 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29E99106566C for ; Sat, 25 Feb 2012 16:32:25 +0000 (UTC) (envelope-from wojtek@tensor.gdynia.pl) Received: from tensor.gdynia.pl (tensor.gdynia.pl [89.206.35.72]) by mx1.freebsd.org (Postfix) with ESMTP id 867D48FC15 for ; Sat, 25 Feb 2012 16:32:24 +0000 (UTC) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by tensor.gdynia.pl (8.14.4/8.14.5) with ESMTP id q1PG64Nd002292; Sat, 25 Feb 2012 17:06:04 +0100 (CET) (envelope-from wojtek@tensor.gdynia.pl) Received: (from wojtek@localhost) by tensor.gdynia.pl (8.14.5/8.14.5/Submit) id q1PG64Yx002291; Sat, 25 Feb 2012 17:06:04 +0100 (CET) (envelope-from wojtek) Newsgroups: Date: Sat, 25 Feb 2012 16:45:52 +0100 (CET) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Fcc: sent-mail Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-Cursor-Pos: : 0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=UTF-8 Status: X-Status: X-Keywords: X-UID: 1 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.6 (tensor.gdynia.pl [89.206.35.72]); Sat, 25 Feb 2012 17:06:04 +0100 (CET) Cc: Grzegorz Kulewski Subject: improving VM - questions X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 16:32:25 -0000 it is easy to see that VM settings are not fine for MODERN hardware. We have gigabytes, not megabytes of RAM, hard disks can be efficient only if average I/O size is in order of megabyte or so, not tens of kB. In spite of having gigabytes of RAM, sometimes we DO NEED swapping. often we have process taking lots of RAM that is not used for a long etc. For now swapping generates too small I/Os i tried that patch --- swap_pager.c.orig 2012-02-25 16:22:25.000000000 +0100 +++ swap_pager.c 2012-02-25 13:19:51.000000000 +0100 @@ -119,7 +119,7 @@ * The 32-page limit is due to the radix code (kern/subr_blist.c). */ #ifndef MAX_PAGEOUT_CLUSTER -#define MAX_PAGEOUT_CLUSTER 16 +#define MAX_PAGEOUT_CLUSTER 256 #endif #if !defined(SWB_NPAGES) --- vm_fault.c.orig 2011-10-12 22:08:25.000000000 +0200 +++ vm_fault.c 2012-02-25 13:20:02.000000000 +0100 @@ -114,8 +114,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 128 +#define VM_FAULT_READ_BEHIND 127 #define VM_FAULT_READ (VM_FAULT_READ_AHEAD+VM_FAULT_READ_BEHIND+1) struct faultstate { --- param.h~ 2011-06-08 05:45:40.000000000 +0200 +++ param.h 2011-06-15 19:00:32.000000000 +0200 @@ -131,7 +131,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 (2048 * 1024) /* max raw I/O transfer size */ #endif #ifndef MAXDUMPPGS #define MAXDUMPPGS (DFLTPHYS/PAGE_SIZE) ----- param.h patch works great for filesystem I/O with big files. i use it for a long. vm_fault.c patch seems to make starting big programs faster as well, systat/vmstat confirms I/O sizes are larger. but swap_pager.c patch seems not to work. i observe 64kB pageouts, no more. what is wrong in it? Other question - tmpfs, it not in memory, seems to ALWAYS generate exactly one page sized I/Os at pagein (no matter what i do). What is wrong in it?