From: Russell King <rmk@arm.linux.org.uk>
To: Roger Larsson <roger.larsson@skelleftea.mail.telia.com>
Cc: Stephan von Krawczynski <skraw@ithnet.com>,
Daniel Phillips <phillips@bonn-fries.net>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-mm@kvack.org
Subject: Re: [PATCH] __alloc_pages cleanup -R6 Was: Re: Memory Problem in 2.4.10-pre2 / __alloc_pages failed
Date: Fri, 31 Aug 2001 08:43:35 +0100 [thread overview]
Message-ID: <20010831084335.A4222@flint.arm.linux.org.uk> (raw)
In-Reply-To: <20010829140706.3fcb735c.skraw@ithnet.com> <20010829232929Z16206-32383+2351@humbolt.nl.linux.org> <20010830164634.3706d8f8.skraw@ithnet.com> <200108302357.BAA11235@mailb.telia.com>
In-Reply-To: <200108302357.BAA11235@mailb.telia.com>; from roger.larsson@skelleftea.mail.telia.com on Fri, Aug 31, 2001 at 01:53:24AM +0200
On Fri, Aug 31, 2001 at 01:53:24AM +0200, Roger Larsson wrote:
> Some ideas implemented in this code:
> * Reserve memory below min for atomic and recursive allocations.
> * When being min..low on free pages, free one more than you want to allocate.
> * When being low..high on free pages, free one less than wanted.
> * When above high - don't free anything.
> * First select zones with more than high free memory.
> * Then those with more than high 'free + inactive_clean - inactive_target'
> * When freeing - do it properly. Don't steal direct reclaimed pages
Hmm, I wonder.
I have a 1MB DMA zone, and 31MB of normal memory.
The machine has been running lots of programs for some time, but not under
any VM pressure. I now come to open a device which requires 64K in 8K
pages from the DMA zone. What happens?
I suspect that the chances of it failing will be significantly higher with
this algorithm - do you have any thoughts for this?
I don't think we should purely select the allocation zone based purely on
how much free it contains, but also if it's special (like the DMA zone).
You can't clean in-use slab pages out on demand like you can for fs
cache/user pages.
--
Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
WARNING: multiple messages have this Message-ID (diff)
From: Russell King <rmk@arm.linux.org.uk>
To: Roger Larsson <roger.larsson@skelleftea.mail.telia.com>
Cc: Stephan von Krawczynski <skraw@ithnet.com>,
Daniel Phillips <phillips@bonn-fries.net>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-mm@kvack.org
Subject: Re: [PATCH] __alloc_pages cleanup -R6 Was: Re: Memory Problem in 2.4.10-pre2 / __alloc_pages failed
Date: Fri, 31 Aug 2001 08:43:35 +0100 [thread overview]
Message-ID: <20010831084335.A4222@flint.arm.linux.org.uk> (raw)
In-Reply-To: <200108302357.BAA11235@mailb.telia.com>; from roger.larsson@skelleftea.mail.telia.com on Fri, Aug 31, 2001 at 01:53:24AM +0200
On Fri, Aug 31, 2001 at 01:53:24AM +0200, Roger Larsson wrote:
> Some ideas implemented in this code:
> * Reserve memory below min for atomic and recursive allocations.
> * When being min..low on free pages, free one more than you want to allocate.
> * When being low..high on free pages, free one less than wanted.
> * When above high - don't free anything.
> * First select zones with more than high free memory.
> * Then those with more than high 'free + inactive_clean - inactive_target'
> * When freeing - do it properly. Don't steal direct reclaimed pages
Hmm, I wonder.
I have a 1MB DMA zone, and 31MB of normal memory.
The machine has been running lots of programs for some time, but not under
any VM pressure. I now come to open a device which requires 64K in 8K
pages from the DMA zone. What happens?
I suspect that the chances of it failing will be significantly higher with
this algorithm - do you have any thoughts for this?
I don't think we should purely select the allocation zone based purely on
how much free it contains, but also if it's special (like the DMA zone).
You can't clean in-use slab pages out on demand like you can for fs
cache/user pages.
--
Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
--
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-mm.org/
next prev parent reply other threads:[~2001-08-31 7:43 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-08-29 12:07 Memory Problem in 2.4.10-pre2 / __alloc_pages failed Stephan von Krawczynski
2001-08-29 16:47 ` Roger Larsson
2001-08-29 19:18 ` Stephan von Krawczynski
[not found] ` <Pine.LNX.4.33.0108300521280.448-100000@mikeg.weiden.de>
2001-08-30 14:16 ` Stephan von Krawczynski
2001-08-29 23:36 ` Daniel Phillips
2001-08-30 14:46 ` Stephan von Krawczynski
2001-08-30 18:02 ` Daniel Phillips
2001-08-31 10:32 ` Stephan von Krawczynski
2001-08-30 23:53 ` [PATCH] __alloc_pages cleanup -R6 Was: " Roger Larsson
2001-08-30 23:53 ` Roger Larsson
2001-08-31 7:43 ` Russell King [this message]
2001-08-31 7:43 ` Russell King
2001-08-31 23:22 ` Roger Larsson
2001-08-31 23:22 ` Roger Larsson
2001-08-30 16:49 ` Roger Larsson
2001-08-31 11:06 ` Stephan von Krawczynski
2001-08-31 19:03 ` Daniel Phillips
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=20010831084335.A4222@flint.arm.linux.org.uk \
--to=rmk@arm.linux.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=phillips@bonn-fries.net \
--cc=roger.larsson@skelleftea.mail.telia.com \
--cc=skraw@ithnet.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 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.