linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Tom Leete <tleete@mountain.net>
To: Rik van Riel <riel@conectiva.com.br>
Cc: linux-mm@kvack.org, Linus Torvalds <torvalds@transmeta.com>
Subject: Re: [PATCH] fix for VM  test9-pre7
Date: Mon, 02 Oct 2000 08:27:38 -0400	[thread overview]
Message-ID: <39D87F3A.7D21E18@mountain.net> (raw)
In-Reply-To: <Pine.LNX.4.21.0010020038090.30717-100000@duckman.distro.conectiva>

[-- Attachment #1: Type: text/plain, Size: 1239 bytes --]

Rik van Riel wrote:
> 
> Hi,
> 
> The attached patch seems to fix all the reported deadlock
> problems with the new VM. Basically they could be grouped
> into 2 categories:
> 
> 1) __GFP_IO related locking issues
> 2) something sleeps on a free/clean/inactive page goal
>    that isn't worked towards
> 
> The patch has survived some heavy stresstesting on both
> SMP and UP machines. I hope nobody will be able to find
> a way to still crash this one ;)
> 
> A second change is a more dynamic free memory target
> (now freepages.high + inactive_target / 3), this seems
> to help a little bit in some loads.
> 

Hi,

I ran lmbench on test9-pre7 with and without the patch.

Test machine was a slow medium memory UP box:
Cx586@120Mhz, no optimizations, 56M

I still experience instability on this machine with both the
patched and vanilla kernel. It usually takes the form of
sudden total lockups, but on occasion I have seen oops +
panic at boot.

This summary doesn't show any performance advantage to the
patch, but the detailed plots show that memory access
latency degrades more gracefully wrt array size.

For bandwidth, I'm only including the summary. Vanilla is
listed first in each entry. Full lmbench report files on
request.

Tom

[-- Attachment #2: vanilla-vs-riel --]
[-- Type: text/plain, Size: 3081 bytes --]


                 L M B E N C H  1 . 9   S U M M A R Y
                 ------------------------------------
		 (Alpha software, do not distribute)

Processor, Processes - times in microseconds - smaller is better
----------------------------------------------------------------
Host                 OS  Mhz null null      open selct sig  sig  fork exec sh  
                             call  I/O stat clos       inst hndl proc proc proc
--------- ------------- ---- ---- ---- ---- ---- ----- ---- ---- ---- ---- ----
i486-linu Linux 2.4.0-t  119  1.8  4.0   51   62 0.33K  9.2   19 4.3K  16K  54K
i486-linu Linux 2.4.0-p  119  1.8  4.1   51   64 0.35K  9.2   19 4.5K  16K  55K

Context switching - times in microseconds - smaller is better
-------------------------------------------------------------
Host                 OS 2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K
                        ctxsw  ctxsw  ctxsw ctxsw  ctxsw   ctxsw   ctxsw
--------- ------------- ----- ------ ------ ------ ------ ------- -------
i486-linu Linux 2.4.0-t    2    388   1054   296   1733     439    1854
i486-linu Linux 2.4.0-p    5    308   1062   268   1650     416    1822

*Local* Communication latencies in microseconds - smaller is better
-------------------------------------------------------------------
Host                 OS 2p/0K  Pipe AF     UDP  RPC/   TCP  RPC/ TCP
                        ctxsw       UNIX         UDP         TCP conn
--------- ------------- ----- ----- ---- ----- ----- ----- ----- ----
i486-linu Linux 2.4.0-t     2    44  131   352         628       2267
i486-linu Linux 2.4.0-p     5    47  109   401         649       2186

File & VM system latencies in microseconds - smaller is better
--------------------------------------------------------------
Host                 OS   0K File      10K File      Mmap    Prot    Page	
                        Create Delete Create Delete  Latency Fault   Fault 
--------- ------------- ------ ------ ------ ------  ------- -----   ----- 
i486-linu Linux 2.4.0-t    110     18    337     39     2702     5    0.0K
i486-linu Linux 2.4.0-p    111     20    340     42     2829     4    0.0K

*Local* Communication bandwidths in MB/s - bigger is better
-----------------------------------------------------------
Host                OS  Pipe AF    TCP  File   Mmap  Bcopy  Bcopy  Mem   Mem
                             UNIX      reread reread (libc) (hand) read write
--------- ------------- ---- ---- ---- ------ ------ ------ ------ ---- -----
i486-linu Linux 2.4.0-t   15    6    6      9     32     14     14   32    39
i486-linu Linux 2.4.0-p   14    7    6     10     32     14     14   32    39

Memory latencies in nanoseconds - smaller is better
    (WARNING - may not be correct, check graphs)
---------------------------------------------------
Host                 OS   Mhz  L1 $   L2 $    Main mem    Guesses
--------- -------------   ---  ----   ----    --------    -------
i486-linu Linux 2.4.0-t   119    25    419         452    No L2 cache?
i486-linu Linux 2.4.0-p   119    25    365         459

  parent reply	other threads:[~2000-10-02 12:27 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-10-02  3:42 Rik van Riel
2000-10-02  8:18 ` Roger Larsson
2000-10-02 10:00   ` Ignore my: " Roger Larsson
2000-10-02 15:48     ` Rik van Riel
2000-10-02 15:45   ` Rik van Riel
2000-10-02 12:05 ` ehrhardt
2000-10-02 15:49   ` Rik van Riel
2000-10-02 12:27 ` Tom Leete [this message]
2000-10-02 15:51   ` Rik van Riel
2000-10-02 21:20     ` Tom Leete
2000-10-02 16:46 ` Christoph Rohland
2000-10-02 17:17   ` Rik van Riel
2000-10-04  7:45     ` Christoph Rohland

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=39D87F3A.7D21E18@mountain.net \
    --to=tleete@mountain.net \
    --cc=linux-mm@kvack.org \
    --cc=riel@conectiva.com.br \
    --cc=torvalds@transmeta.com \
    /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