SWAP: Linux far behind Solaris or I missed something (fwd)

SWAP: Linux far behind Solaris or I missed something (fwd)

[Rik van Riel]

Hi,

I think we really should be working on this -- anybody
got a suggestion?

(although the 2.1.130+my patch seems to work very well
with extremely high swap throughput)

cheers,

Rik -- the flu hits, the flu hits, the flu hits -- MORE
+-------------------------------------------------------------------+
| Linux memory management tour guide.        H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader.      http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+

---------- Forwarded message ----------
Date: Wed, 02 Dec 1998 16:49:30 +0100
From: Jean-Michel VANSTEENE <Jean-Michel.Vansteene@bull.net>
To: linux-kernel <linux-kernel@vger.rutgers.edu>
Subject: SWAP: Linux far behind Solaris or I missed something

I've made some tests to load a computer (1GB memory).
A litle process starts eating 900 MB then slowly eats 
the remainder of the memory 1MB by 1MB and does a
"data shake": 200,000 times a memcpy of 4000 bytes 
randomly choosen.

I want to test the swap capability.

Solaris was used under XWindow, Linux under text
console... What do I forget to comfigure or tune?
Don't let me with such bad values.......

------------------------------------------------	
I removed micro seconds displayed by my function
after call to gettimeofday

megs    Solaris      Linux
------------------------------------------------
901:    18 secs      9 secs
902:    11 secs      9 secs
903:    10 secs      9 secs
904:    9 secs       9 secs
905:    9 secs       9 secs
906:    9 secs       9 secs
907:    9 secs       9 secs
908:    9 secs       9 secs
909:    9 secs       9 secs
910:    9 secs       13 secs
911:    9 secs       17 secs
912:    9 secs       20 secs
913:    9 secs       24 secs
914:    9 secs       33 secs
915:    10 secs      44 secs
916:    9 secs       56 secs
917:    9 secs       65 secs
918:    9 secs       75 secs
919:    9 secs       81 secs
920:    9 secs       87 secs
921:    9 secs       96 secs
922:    9 secs       108 secs
923:    9 secs       122 secs
924:    9 secs       129 secs
925:    9 secs       142 secs
926:    9 secs       155 secs
927:    9 secs       161 secs

928 - 977  always  9 secs under solaris

978:    10 secs      <stop testing>
979:    10 secs       -------
980:    11 secs
981:    14 secs
982:    17 secs
983:    21 secs
984:    28 secs
985:    32 secs
986:    26 secs
987:    18 secs
988:    19 secs
989:    24 secs
990:    29 secs
991:    41 secs
992:    48 secs
993:    85 secs
994:    86 secs
995:    91 secs
996:    92 secs
997:    93 secs
998:    97 secs
999:    83 secs

------------------------------------------------

-- 
*--* mailto:Jean-Michel.Vansteene@bull.net  (Bull)
*--* mailto:vanstee@worldnet.fr             (Home)
*--* http://www.worldnet.fr/~vanstee        (Jean GABIN)
-------------------------------------------------------------
- - - - - U n   L i n u x   s i n o n   r i e n - - - - - - -

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org

Re: SWAP: Linux far behind Solaris or I missed something (fwd)

[Neil Conway]

Rik van Riel wrote:
> 
> Hi,
> 
> I think we really should be working on this -- anybody
> got a suggestion?
> 
> (although the 2.1.130+my patch seems to work very well
> with extremely high swap throughput)


Since the poster didn't say otherwise, perhaps this test was performed
with buffermem/pagecache.min_percent set to their default values, which
IIRC add up to 13% of physical RAM (in fact that's PHYSICAL ram, not 13%
of available RAM).  So take a 1024MB machine, with (say) roughly 16MB
used by the kernel and kernel-data.  Then subtract 0.13*1024 (133MB !!)
and you're left with a paltry 875MB or so.  (This assumes that the
poster had modified his kernel to handle the full 1024MB btw).

So in fact the cache/buffers probably weren't quite filled to their min.
values or swapping and poor performance would have set in even earlier
than they did (910MB).

It's worth taking note I suppose that Solaris *doesn't* have this
problem.  It's probably not worth a kernel patch to fix the Linux
behaviour though; I just reset the values to more sane ones in rc.local.

Now let's see if Linux does any better with say 2% for each of the min
values...

Neil
PS: to Jean-Michel: in case you don't know what I mean (though I assume
you do), look at /proc/sys/vm/pagecache and buffermem, and
Documentation/sysctl/ 
PPS: I presume that the initial sluggishness of Solaris was due to it
throwing away some cache?


> 
> ---------- Forwarded message ----------
> Date: Wed, 02 Dec 1998 16:49:30 +0100
> From: Jean-Michel VANSTEENE <Jean-Michel.Vansteene@bull.net>
> To: linux-kernel <linux-kernel@vger.rutgers.edu>
> Subject: SWAP: Linux far behind Solaris or I missed something
> 
> I've made some tests to load a computer (1GB memory).
> A litle process starts eating 900 MB then slowly eats
> the remainder of the memory 1MB by 1MB and does a
> "data shake": 200,000 times a memcpy of 4000 bytes
> randomly choosen.
> 
> I want to test the swap capability.
> 
> Solaris was used under XWindow, Linux under text
> console... What do I forget to comfigure or tune?
> Don't let me with such bad values.......
> 
> ------------------------------------------------
> I removed micro seconds displayed by my function
> after call to gettimeofday
> 
> megs    Solaris      Linux
> ------------------------------------------------
> 901:    18 secs      9 secs
> 902:    11 secs      9 secs
> 903:    10 secs      9 secs
> 904:    9 secs       9 secs
> 905:    9 secs       9 secs
> 906:    9 secs       9 secs
> 907:    9 secs       9 secs
> 908:    9 secs       9 secs
> 909:    9 secs       9 secs
> 910:    9 secs       13 secs
> 911:    9 secs       17 secs
> 912:    9 secs       20 secs
> 913:    9 secs       24 secs
> 914:    9 secs       33 secs
> 915:    10 secs      44 secs
> 916:    9 secs       56 secs
> 917:    9 secs       65 secs
> 918:    9 secs       75 secs
> 919:    9 secs       81 secs
> 920:    9 secs       87 secs
> 921:    9 secs       96 secs
> 922:    9 secs       108 secs
> 923:    9 secs       122 secs
> 924:    9 secs       129 secs
> 925:    9 secs       142 secs
> 926:    9 secs       155 secs
> 927:    9 secs       161 secs
> 
> 928 - 977  always  9 secs under solaris
> 
> 978:    10 secs      <stop testing>
> 979:    10 secs       -------
> 980:    11 secs
> 981:    14 secs
> 982:    17 secs
> 983:    21 secs
> 984:    28 secs
> 985:    32 secs
> 986:    26 secs
> 987:    18 secs
> 988:    19 secs
> 989:    24 secs
> 990:    29 secs
> 991:    41 secs
> 992:    48 secs
> 993:    85 secs
> 994:    86 secs
> 995:    91 secs
> 996:    92 secs
> 997:    93 secs
> 998:    97 secs
> 999:    83 secs
--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org

Re: SWAP: Linux far behind Solaris or I missed something (fwd)

[Stephen C. Tweedie]

Hi,

On Thu, 3 Dec 1998 13:03:35 +0100 (CET), Rik van Riel
<H.H.vanRiel@phys.uu.nl> said:

> Hi,
> I think we really should be working on this -- anybody
> got a suggestion?

Depends on what the program is doing:

> I've made some tests to load a computer (1GB memory).
> A litle process starts eating 900 MB then slowly eats 
> the remainder of the memory 1MB by 1MB and does a
> "data shake": 200,000 times a memcpy of 4000 bytes 
> randomly choosen.

are these 4000 bytes chosen randomly from the 1MB currently being
"eaten", or from the whole block of memory currently "eaten"?  That
makes a huge difference to the problem.  What kernel is this, anyway?

--Stephen
--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org

Re: SWAP: Linux far behind Solaris or I missed something (fwd)

[Stephen C. Tweedie]

Hi,

On Fri, 04 Dec 1998 14:35:47 +0100, Jean-Michel VANSTEENE
<Jean-Michel.Vansteene@bull.net> said:

> Randomly from the whole block of memory. I know this is really a
> memory shake. But i would like to figure out if the swap heavily
> penalizes the performance. Or, in other words, the percentage of
> swap usage after which performances are too low....

Which kernel, and could you show a "vmstat 1" run for the duration of
one of these tests?

Thanks,
 Stephen.
--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org

Re: SWAP: Linux far behind Solaris or I missed something (fwd)

[Stephen C. Tweedie]

Hi,

On Fri, 4 Dec 1998 10:41:15 +0000, Neil Conway
<nconway.list@ukaea.org.uk> said:

>> (although the 2.1.130+my patch seems to work very well
>> with extremely high swap throughput)

> Since the poster didn't say otherwise, perhaps this test was performed
> with buffermem/pagecache.min_percent set to their default values, which
> IIRC add up to 13% of physical RAM (in fact that's PHYSICAL ram, not 13%
> of available RAM).  So take a 1024MB machine, with (say) roughly 16MB
> used by the kernel and kernel-data.  Then subtract 0.13*1024 (133MB !!)
> and you're left with a paltry 875MB or so.  (This assumes that the
> poster had modified his kernel to handle the full 1024MB btw).

I know.  That's why relying on fixed margins to ensure good
performance is wrong: the system really ought to be self-tuning.
We may yet get it right for 2.2: there are people working on this.

--Stephen
--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org

Re: SWAP: Linux far behind Solaris or I missed something (fwd)

[Rik van Riel]

On Fri, 4 Dec 1998, Stephen C. Tweedie wrote:
> On Fri, 4 Dec 1998 10:41:15 +0000, Neil Conway
> <nconway.list@ukaea.org.uk> said:
> 
> >> (although the 2.1.130+my patch seems to work very well
> >> with extremely high swap throughput)
> 
> > Since the poster didn't say otherwise, perhaps this test was performed
> > with buffermem/pagecache.min_percent set to their default values, which
> > IIRC add up to 13% of physical RAM (in fact that's PHYSICAL ram, not 13%
> 
> I know.  That's why relying on fixed margins to ensure good
> performance is wrong: the system really ought to be self-tuning.
> We may yet get it right for 2.2: there are people working on this.

It appears that 2.1.130 + my little patches only needs the
borrow percentage (otherwise kswapd doesn't have enough
reason to switch from the always-succesful swap_out()),
and that only needs to be set to a high value...
(ie. /not/ the braindead values that went into 2.1.131)

cheers,

Rik -- the flu hits, the flu hits, the flu hits -- MORE
+-------------------------------------------------------------------+
| Linux memory management tour guide.        H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader.      http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+

--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org

Re: SWAP: Linux far behind Solaris or I missed something (fwd)

[MOLNAR Ingo]

On Fri, 4 Dec 1998, Rik van Riel wrote:

> > I know.  That's why relying on fixed margins to ensure good
> > performance is wrong: the system really ought to be self-tuning.
> > We may yet get it right for 2.2: there are people working on this.
> 
> It appears that 2.1.130 + my little patches only needs the
> borrow percentage (otherwise kswapd doesn't have enough
> reason to switch from the always-succesful swap_out()),
> and that only needs to be set to a high value...

'borrow percentage' is just yet another arbitrary parameter (*). The
solution is not to increase the number of parameters and tweak them until
there is more or less ok fit on all testcases! (i know that borrow
percentage was there originally) The task is to _decrease_ the number of
parameters as much as possible. (preferably no 'number' parameters at all,
just one basic self-tuning framework) [Unfortunately this is much much
harder than adding parameters, it needs a thorough understanding of all
issues involved.]

-- mingo

(*) parameter: degree of freedom in an algorithm, both kernel-source
    compiled-in constants/tweaks/rules and user-supplied (possibly
    runtime) parameters.

--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org