All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Rohland <cr@sap.com>
To: Rik van Riel <riel@conectiva.com.br>
Cc: Jonathan George <Jonathan.George@trcinc.com>,
	"'matthew@mattshouse.com'" <matthew@mattshouse.com>,
	"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: Re: 2.4.0-test10 Sluggish After Load
Date: 04 Nov 2000 21:04:10 +0100	[thread overview]
Message-ID: <m3bsvvh5c5.fsf@linux.local> (raw)
In-Reply-To: <Pine.LNX.4.05.10011041403590.4511-100000@humbolt.nl.linux.org>

Hi Rik,

Rik van Riel <riel@conectiva.com.br> writes:
> Indeed, shared memory performance still sucks rocks.

No, it's not a performance problem. It is a hard lockup problem on
highmem machines.

I do see two problems here:
1) shm_swap_core does not handle the failure of prepare_higmem_swapout
   right and basically cannot do so. It gets called zone independant
   and should probably get called per zone. At least it has to react:
   If the lowmem zone is full it should not try to swap out highmem
   pages. I have a little workaround for that. Unfortunately this is
   not the whole thing:
2) Apparently the vm does not handle the case, where it has hardly any
   pages in the queues. My machine locks up with the following memory
   numbers:

SysRq: Show Memory
Mem-info:
Free pages:        2560kB (  1028kB HighMem)
( Active: 5, inactive_dirty: 27, inactive_clean: 27, free: 640 (638 1276 1914) )0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 1*512kB 0*1024kB 0*2048kB = 512kB)
7*4kB 14*8kB 1*16kB 1*32kB 1*64kB 0*128kB 1*256kB 1*512kB 0*1024kB 0*2048kB = 1020kB)
3*4kB 1*8kB 1*16kB 1*32kB 1*64kB 1*128kB 1*256kB 1*512kB 0*1024kB 0*2048kB = 1028kB)
Swap cache: add 31231, delete 31218, find 21433/21531
Free swap:       1961028kB
2162688 pages of RAM
1867776 pages of HIGHMEM
102296 reserved pages
1204551 pages shared
13 pages swap cached
0 pages in page table cache
Buffer memory:      100kB
    CLEAN: 2 buffers, 8 kbyte, 2 used (last=2), 0 locked, 0 protected, 0 dirty
   LOCKED: 25 buffers, 100 kbyte, 25 used (last=25), 2 locked, 0
   protected, 0 dirty  

You see: you only have 5+27+27=59 pages under your control...

> I have not had time to fix this and I'm afraid I probably
> won't have time to fix this in the near future. I'm willing
> to give some advice to people who do want to take on the job
> of fixing SHM performance, though..

As you know I started this some time before, but nobody helped me in
integrating it into the rest of the VM :-( 

Unfortunately my time is very limited, but I probably would give it a
second try since I think shm swapping should work. But I think a clean
integration is a 2.5 issue.

Greetings
                Christoph

-
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/

  reply	other threads:[~2000-11-04 20:03 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-11-01 15:44 2.4.0-test10 Sluggish After Load Jonathan George
2000-11-01 16:05 ` Rik van Riel
2000-11-03 12:54   ` Christoph Rohland
2000-11-04 13:05     ` Rik van Riel
2000-11-04 20:04       ` Christoph Rohland [this message]
2000-11-05 13:36         ` Rik van Riel
2000-11-05 18:49           ` Christoph Rohland
  -- strict thread matches above, loose matches on Subject: below --
2000-11-01 16:18 Jonathan George
2000-11-01 16:56 ` Rik van Riel
2000-11-02  8:48   ` Christoph Rohland
2000-11-02 13:52     ` Rik van Riel
2000-11-02 16:22       ` matthew
2000-11-04  1:31         ` Peter Samuelson
2000-11-01 16:59 ` matthew
2000-11-01 17:11   ` Rik van Riel
2000-11-01 15:00 matthew
2000-11-01 15:26 ` Sean Hunter
2000-11-01 17:10   ` matthew
2000-11-01 17:13     ` Sean Hunter
2000-11-01 17:29       ` Rik van Riel
2000-11-02 11:09   ` Alessandro Suardi

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=m3bsvvh5c5.fsf@linux.local \
    --to=cr@sap.com \
    --cc=Jonathan.George@trcinc.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthew@mattshouse.com \
    --cc=riel@conectiva.com.br \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.