improving VM - questions

[Wojciech Puchar-5]

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?


_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"

[Andriy Gapon]

on 25/02/2012 17:45 Wojciech Puchar said the following:
[snip]

> 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

[snip]
> but swap_pager.c patch seems not to work. i observe 64kB pageouts, no more.
>
> what is wrong in it?

Could there be a problem because of what the MAX_PAGEOUT_CLUSTER comment says?

--
Andriy Gapon
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"

[Wojciech Puchar-5]

>> +++ 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
> [snip]
>> but swap_pager.c patch seems not to work. i observe 64kB pageouts, no more.
>>
>> what is wrong in it?
>
> Could there be a problem because of what the MAX_PAGEOUT_CLUSTER comment says?

right. but still 32 pages is 128kB, but i see 64kB I/Os in systat/vmstat

>
> --
> Andriy Gapon
> _______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "[hidden email]"
>
>

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"

[Andriy Gapon]

on 28/02/2012 11:43 Wojciech Puchar said the following:

>>> +++ 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
>> [snip]
>>> but swap_pager.c patch seems not to work. i observe 64kB pageouts, no more.
>>>
>>> what is wrong in it?
>>
>> Could there be a problem because of what the MAX_PAGEOUT_CLUSTER comment says?
>
> right. but still 32 pages is 128kB, but i see 64kB I/Os in systat/vmstat

Right, but the comment says to not define MAX_PAGEOUT_CLUSTER to a value greater
than 32, but you did that.  So all bets could be off unless you examined the
code and know exactly what should happen in this case.


--
Andriy Gapon
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"

[Artem Belevich-3]

On Tue, Feb 28, 2012 at 2:21 AM, Andriy Gapon <[hidden email]> wrote:

> on 28/02/2012 11:43 Wojciech Puchar said the following:
>>>> +++ 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
>>> [snip]
>>>> but swap_pager.c patch seems not to work. i observe 64kB pageouts, no more.
>>>>
>>>> what is wrong in it?
>>>
>>> Could there be a problem because of what the MAX_PAGEOUT_CLUSTER comment says?
>>
>> right. but still 32 pages is 128kB, but i see 64kB I/Os in systat/vmstat
>
> Right, but the comment says to not define MAX_PAGEOUT_CLUSTER to a value greater
> than 32, but you did that.  So all bets could be off unless you examined the
> code and know exactly what should happen in this case.

I suspect it might be DFLTPHYS that splits disk i/o into 64K blocks on
the driver level.

--Artem

>
>
> --
> Andriy Gapon
> _______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "[hidden email]"
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"

[Wojciech Puchar-5]

>>> right. but still 32 pages is 128kB, but i see 64kB I/Os in systat/vmstat
>>
>> Right, but the comment says to not define MAX_PAGEOUT_CLUSTER to a value greater
>> than 32, but you did that.  So all bets could be off unless you examined the
>> code and know exactly what should happen in this case.
>
> I suspect it might be DFLTPHYS that splits disk i/o into 64K blocks on
> the driver level.
can i increase DFLTPHYS as well as i did with MAXPHYS without problems?
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"

[Artem Belevich-3]

On Tue, Feb 28, 2012 at 1:06 PM, Wojciech Puchar
<[hidden email]> wrote:
>>>> right. but still 32 pages is 128kB, but i see 64kB I/Os in systat/vmstat
>>>
>>> Right, but the comment says to not define MAX_PAGEOUT_CLUSTER to a value greater
>>> than 32, but you did that.  So all bets could be off unless you examined the
>>> code and know exactly what should happen in this case.
>>
>> I suspect it might be DFLTPHYS that splits disk i/o into 64K blocks on
>> the driver level.
> can i increase DFLTPHYS as well as i did with MAXPHYS without problems?

Sorry, I don't have definitive answer to that.

This old post has some related info:
http://lists.freebsd.org/pipermail/freebsd-performance/2008-February/003311.html

Even older thread on freebsd-arch also described some concerns:
http://lists.freebsd.org/pipermail/freebsd-arch/2004-January/001590.html

I don't know whether the stuff above still applies to FreeBSD as it is now:

--Artem
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"