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
next prev 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