linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Neil Conway <nconway.list@ukaea.org.uk>
To: Rik van Riel <H.H.vanRiel@phys.uu.nl>
Cc: Linux MM <linux-mm@kvack.org>,
	Jean-Michel.Vansteene@bull.net,
	"linux-kernel@vger.rutgers.edu" <linux-kernel@vger.rutgers.edu>
Subject: Re: SWAP: Linux far behind Solaris or I missed something (fwd)
Date: Fri, 4 Dec 1998 10:41:15 +0000	[thread overview]
Message-ID: <98Dec4.104023gmt.66305@gateway.ukaea.org.uk> (raw)
In-Reply-To: <Pine.LNX.3.96.981203130156.1008D-100000@mirkwood.dummy.home>

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

  reply	other threads:[~1998-12-04 10:42 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-12-03 12:03 Rik van Riel
1998-12-04 10:41 ` Neil Conway [this message]
1998-12-04 14:49   ` Stephen C. Tweedie
1998-12-04 15:23     ` Rik van Riel
1998-12-05  7:51       ` MOLNAR Ingo
1998-12-04 12:05 ` Stephen C. Tweedie
     [not found]   ` <3667E533.ADFBFDBB@bull.net>
1998-12-04 14:47     ` Stephen C. Tweedie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=98Dec4.104023gmt.66305@gateway.ukaea.org.uk \
    --to=nconway.list@ukaea.org.uk \
    --cc=H.H.vanRiel@phys.uu.nl \
    --cc=Jean-Michel.Vansteene@bull.net \
    --cc=linux-kernel@vger.rutgers.edu \
    --cc=linux-mm@kvack.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox