linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Rik van Riel <riel@conectiva.com.br>
To: Ying Chen/Almaden/IBM <ying@almaden.ibm.com>
Cc: linux-mm@kvack.org, Andrea Arcangeli <andrea@suse.de>,
	Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH] fix for VM test9-pre,
Date: Mon, 2 Oct 2000 14:07:51 -0300 (BRST)	[thread overview]
Message-ID: <Pine.LNX.4.21.0010021400420.22539-100000@duckman.distro.conectiva> (raw)
In-Reply-To: <OF28EE4EE0.DBB104BA-ON8825696C.005977FC@LocalDomain>

On Mon, 2 Oct 2000, Ying Chen/Almaden/IBM wrote:

> There are a couple strange behavior I saw with this vm patch on
> my box. I ran Linux test9-pre7 with the newest vmpatch in on a
> Dell PowerEdge with 2 GB memory.
> 
> This patch seems to make interactive applications run with very very long
> response times when memory is short space.

> Example 1: If I do mke2fs on a 90GB file system, after halfway
> through making the file system, the lower 1GB is filled up. mkfs
> takes practically for ever to finish. I checked the sysrq-m
> output, DMA has only 512K buffer, NORMAL has 1020K, HIGHMEM has
> 1 GB. When this happens, I basically cannot do anything, not
> even ls, df, top, etc. They all take for ever to run. If I kill
> mkfs, (closing the telnet sessions that mkfs was in) things
> starts to come back alive. It almost feels like something got
> stuck somewhere.

> Eample 2: I ran SPEC SFS tests to stress the Linux box. During
> the tests, the lower memory will be filled up with inode cache
> and dcache entries, while HIGHMEM is not quite used at all. Once
> this happens, again, any interactive commands would take forever
> to finish... Eventually, SPEC SFS would timeout and fail.
> Sometimes, if I managed to kill some processes, I can
> temporarilly get some other applications run. But most of the
> applications would get stuch somewhere very quickly later on.
> 
> I don't see such behavior in test6 though.
> Any ideas?

This is a balancing issue. Since you have 1GB of free memory,
the system tries to use that memory.

However, I have no idea why your buffers and pagecache pages
aren't bounced into the HIGHMEM zone ... They /should/ just
be moved to the HIGHMEM zone where they don't bother the rest
of the system, but for some reason it looks like that doesn't
work right on your system ...

Andrea, Ingo?  Do you have any idea what could be going wrong
here ?

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
       -- Miguel de Icaza, UKUUG 2000

http://www.conectiva.com/		http://www.surriel.com/


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

  reply	other threads:[~2000-10-02 17:07 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-10-02 16:40 Ying Chen/Almaden/IBM
2000-10-02 17:07 ` Rik van Riel [this message]
2000-10-02 19:25   ` Andrea Arcangeli
2000-10-02 19:28     ` Rik van Riel
2000-10-02 19:52       ` Andrea Arcangeli
2000-10-02 19:56         ` Rik van Riel
2000-10-02 19:01 Ying Chen/Almaden/IBM

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=Pine.LNX.4.21.0010021400420.22539-100000@duckman.distro.conectiva \
    --to=riel@conectiva.com.br \
    --cc=andrea@suse.de \
    --cc=linux-mm@kvack.org \
    --cc=mingo@elte.hu \
    --cc=ying@almaden.ibm.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