From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Con Kolivas <kernel@kolivas.org>
Cc: Andrew Morton <akpm@osdl.org>,
ck@vds.kolivas.org, linux list <linux-kernel@vger.kernel.org>,
linux-mm@kvack.org
Subject: Re: [PATCH] mm: limit lowmem_reserve
Date: Sat, 08 Apr 2006 11:25:11 +1000 [thread overview]
Message-ID: <443710F7.3040201@yahoo.com.au> (raw)
In-Reply-To: <200604081101.06066.kernel@kolivas.org>
Con Kolivas wrote:
> On Saturday 08 April 2006 10:55, Nick Piggin wrote:
>
>>Con Kolivas wrote:
>>
>>>On Friday 07 April 2006 22:40, Nick Piggin wrote:
>>>
>>>>How would zone_watermark_ok always fail though?
>>>
>>>Withdrew this patch a while back; ignore
>>
>>Well, whether or not that particular patch isa good idea, it
>>is definitely a bug if zone_watermark_ok could ever always
>>fail due to lowmem reserve and we should fix it.
>
>
> Ok. I think I presented enough information for why I thought zone_watermark_ok
> would fail (for ZONE_DMA). With 16MB ZONE_DMA and a vmsplit of 3GB we have a
> lowmem_reserve of 12MB. It's pretty hard to keep that much ZONE_DMA free, I
> don't think I've ever seen that much free on my ZONE_DMA on an ordinary
> desktop without any particular ZONE_DMA users. Changing the tunable can make
> the lowmem_reserve larger than ZONE_DMA is on any vmsplit too as far as I
> understand the ratio.
>
Umm, for ZONE_DMA allocations, ZONE_DMA isn't a lower zone. So that
12MB protection should never come into it (unless it is buggy?).
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
WARNING: multiple messages have this Message-ID (diff)
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Con Kolivas <kernel@kolivas.org>
Cc: Andrew Morton <akpm@osdl.org>,
ck@vds.kolivas.org, linux list <linux-kernel@vger.kernel.org>,
linux-mm@kvack.org
Subject: Re: [PATCH] mm: limit lowmem_reserve
Date: Sat, 08 Apr 2006 11:25:11 +1000 [thread overview]
Message-ID: <443710F7.3040201@yahoo.com.au> (raw)
In-Reply-To: <200604081101.06066.kernel@kolivas.org>
Con Kolivas wrote:
> On Saturday 08 April 2006 10:55, Nick Piggin wrote:
>
>>Con Kolivas wrote:
>>
>>>On Friday 07 April 2006 22:40, Nick Piggin wrote:
>>>
>>>>How would zone_watermark_ok always fail though?
>>>
>>>Withdrew this patch a while back; ignore
>>
>>Well, whether or not that particular patch isa good idea, it
>>is definitely a bug if zone_watermark_ok could ever always
>>fail due to lowmem reserve and we should fix it.
>
>
> Ok. I think I presented enough information for why I thought zone_watermark_ok
> would fail (for ZONE_DMA). With 16MB ZONE_DMA and a vmsplit of 3GB we have a
> lowmem_reserve of 12MB. It's pretty hard to keep that much ZONE_DMA free, I
> don't think I've ever seen that much free on my ZONE_DMA on an ordinary
> desktop without any particular ZONE_DMA users. Changing the tunable can make
> the lowmem_reserve larger than ZONE_DMA is on any vmsplit too as far as I
> understand the ratio.
>
Umm, for ZONE_DMA allocations, ZONE_DMA isn't a lower zone. So that
12MB protection should never come into it (unless it is buggy?).
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.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-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2006-04-08 1:44 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-02 4:01 2.6.16-ck3 Con Kolivas
2006-04-02 4:46 ` 2.6.16-ck3 Nick Piggin
2006-04-02 8:51 ` 2.6.16-ck3 Con Kolivas
2006-04-02 9:37 ` 2.6.16-ck3 Nick Piggin
2006-04-02 9:39 ` [ck] 2.6.16-ck3 Con Kolivas
2006-04-02 9:51 ` Nick Piggin
2006-04-03 2:48 ` lowmem_reserve question Con Kolivas
2006-04-03 4:42 ` Mike Galbraith
2006-04-03 4:48 ` Con Kolivas
2006-04-03 4:50 ` [ck] " Con Kolivas
2006-04-03 5:14 ` Mike Galbraith
2006-04-03 5:18 ` Con Kolivas
2006-04-03 5:31 ` Mike Galbraith
2006-04-04 2:35 ` [ck] " Con Kolivas
2006-04-06 1:10 ` [PATCH] mm: limit lowmem_reserve Con Kolivas
2006-04-06 1:10 ` Con Kolivas
2006-04-06 1:29 ` Respin: " Con Kolivas
2006-04-06 1:29 ` Con Kolivas
2006-04-06 2:43 ` Andrew Morton
2006-04-06 2:43 ` Andrew Morton
2006-04-06 2:55 ` Con Kolivas
2006-04-06 2:55 ` Con Kolivas
2006-04-06 2:58 ` Con Kolivas
2006-04-06 2:58 ` Con Kolivas
2006-04-06 3:40 ` Andrew Morton
2006-04-06 3:40 ` Andrew Morton
2006-04-06 4:36 ` Con Kolivas
2006-04-06 4:36 ` Con Kolivas
2006-04-06 4:52 ` Con Kolivas
2006-04-06 4:52 ` Con Kolivas
2006-04-07 6:25 ` Nick Piggin
2006-04-07 6:25 ` Nick Piggin
2006-04-07 9:02 ` Con Kolivas
2006-04-07 9:02 ` Con Kolivas
2006-04-07 12:40 ` Nick Piggin
2006-04-07 12:40 ` Nick Piggin
2006-04-08 0:15 ` Con Kolivas
2006-04-08 0:15 ` Con Kolivas
2006-04-08 0:55 ` Nick Piggin
2006-04-08 0:55 ` Nick Piggin
2006-04-08 1:01 ` Con Kolivas
2006-04-08 1:01 ` Con Kolivas
2006-04-08 1:25 ` Nick Piggin [this message]
2006-04-08 1:25 ` Nick Piggin
2006-05-17 14:11 ` Con Kolivas
2006-05-17 14:11 ` Con Kolivas
2006-05-18 7:11 ` Nick Piggin
2006-05-18 7:11 ` Nick Piggin
2006-05-18 7:21 ` Con Kolivas
2006-05-18 7:21 ` Con Kolivas
2006-05-18 7:26 ` Nick Piggin
2006-05-18 7:26 ` Nick Piggin
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=443710F7.3040201@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=akpm@osdl.org \
--cc=ck@vds.kolivas.org \
--cc=kernel@kolivas.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/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.