lkml.org 
[lkml]   [2000]   [Oct]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: VM in v2.4.0test9
From
Date

I'd second that this is most likely a VM related problem. Last few days I
sent you an example that I would make system hang simply by
doing a mkfs on 90 GB file system. This happens when low 1GB memory is used
up (but I still have high 1GB available). I think
David probably ran into the same problem as I did.

I'd trace the problem down a bit. It seems that the system goes into a loop
that consists of the following call sequence:
alloc_pages --> try_to_free_pages --> do_try_to_free_pages (but
doesn't seem to go through page_launder in do_try_to_free_pages) -->
kmem_cache_reap (so skipped the refill_inactive() in the if statement) -->
backto try_again in alloc_pages.
If I kill mkfs, the system would go on nicely for some small applications.
It is still a bit slow.
If I do a "make bzImage", the system would hang again. If I look at the
Sysrq output, I had more than 2000 pages available in inactive_clean list.
I wonder why
alloc_pages doesn't take it.

I had no problem with these kinds of things with test6 or test7.

Ying

Rik van Riel <riel@conectiva.com.br>@vger.kernel.org on 10/04/2000 09:31:21
AM

Sent by: linux-kernel-owner@vger.kernel.org


To: David Weinehall <tao@acc.umu.se>
cc: linux-kernel@vger.kernel.org, Linus Torvalds <torvalds@transmeta.com>
Subject: Re: VM in v2.4.0test9



On Wed, 4 Oct 2000, David Weinehall wrote:

> Running the included program on a clean v2.4.0test9 kernel I can
> hang the computer practically in no time.

> What seems most strange is that the doesn't even get depleated.
> The machine still answers to SysRq and ping, but nothing else.

Looking again at this report in more detail, something
very strange is going on ...

> This is what I got from SysRq+M (manual copy):
>
> Free pages: 500 kB (0 highmem)
> Active: 8 inactive dirty: 1009, inactive clean:0
> free: 125 (31 62 93)

First, you have MORE free memory than freepages.high. In this
case I really don't see why __alloc_pages() wouldn't give the
memory to your processes ....

> Free swap: 64772

And there is tons of swap free...

Are you absolutely sure this is VM related? This almost looks
like the system puts a in a read request but the request queue
doesn't get unplugged, or something strange like that ...

There is more than enough memory to satisfy all VM requests and
the loop in __alloc_pages() is straightforward enough to give
your processes their memory without strange bugs ...

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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/



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

\
 
 \ /
  Last update: 2005-03-22 12:39    [W:0.050 / U:1.180 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site