From: Christoph Rohland <cr@sap.com>
To: Rik van Riel <riel@conectiva.com.br>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: shm swapping in 2.4 again
Date: 15 Nov 2000 21:52:18 +0100 [thread overview]
Message-ID: <qwwem0dyn3x.fsf@sap.com> (raw)
In-Reply-To: <Pine.LNX.4.21.0011151308140.5584-100000@duckman.distro.conectiva>
In-Reply-To: Rik van Riel's message of "Wed, 15 Nov 2000 13:19:26 -0200 (BRDT)"
Hi Rik,
On Wed, 15 Nov 2000, Rik van Riel wrote:
> On 15 Nov 2000, Christoph Rohland wrote:
>
>> - shm_swap is called from swap_out. Actually on my machine after a
>> while it only gets called without __GFP_IO set, which means it
>> will not do anything which again leads to deadlock.
>
> Only _without_ __GFP_IO ? That's not quite right since
> that way the system will never get around to swapping out
> dirty pages...
Yes :-(
>> - If I call this from page_launder it will work much better, but
>> after a while it gets stuck on prepare_highmem_swapout and will
>> again lock up under heavy load.
>
> So calling it from page_launder() is just a workaround to
> make the deadlock more difficult to trigger and not a fix?
It does solve the __GFP_IO issue but triggers another lockup later.
>> 2) Integrating it into the global lru lists and/or the page cache.
>>
>> I think the second approach is the way to go but I do not
>> understand the global lru list handling enough to do this and I
>> do not know if we can do this in the short time.
>
> Indeed, this is the way to go. However, for 2.4 ANY change
> that makes the system work would be a good one ;)
That's what I think. But from my observations I get the impression
that balancing the vm for big shm loads will not work. So the second
approach is perhaps what we have to do to get it working.
Actually I would appreciate some hints, where I could hook into the vm
if I implement a swap_shm_page() which could be called from the
vm. Can I simply call add_to_lru_cache or do I need to add it to the
page cache...
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/
next prev parent reply other threads:[~2000-11-15 21:23 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-11-15 9:19 shm swapping in 2.4 again Christoph Rohland
2000-11-15 9:21 ` Christoph Rohland
2000-11-15 15:19 ` Rik van Riel
2000-11-15 20:52 ` Christoph Rohland [this message]
2000-11-15 21:04 ` Rik van Riel
2000-11-16 8:17 ` Christoph Rohland
2000-11-16 12:01 ` Rik van Riel
2000-11-16 19:17 ` Christoph Rohland
2000-11-16 21:31 ` Christoph Rohland
2000-11-16 21:30 ` Rik van Riel
2000-11-17 8:08 ` 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=qwwem0dyn3x.fsf@sap.com \
--to=cr@sap.com \
--cc=linux-kernel@vger.kernel.org \
--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.