From: Hugh Dickins <hugh@veritas.com>
To: Russell King <rmk+lkml@arm.linux.org.uk>
Cc: Takashi Iwai <tiwai@suse.de>, Lee Revell <rlrevell@joe-job.com>,
Miles Lane <miles.lane@gmail.com>, Andrew Morton <akpm@osdl.org>,
LKML <linux-kernel@vger.kernel.org>,
alsa-devel <alsa-devel@lists.sourceforge.net>
Subject: Re: 2.6.15-rc1-mm2 -- Bad page state at free_hot_cold_page (in process 'aplay', page c18eef30)
Date: Mon, 21 Nov 2005 16:51:14 +0000 (GMT) [thread overview]
Message-ID: <Pine.LNX.4.61.0511211634440.16632@goblin.wat.veritas.com> (raw)
In-Reply-To: <20051121155239.GC21032@flint.arm.linux.org.uk>
On Mon, 21 Nov 2005, Russell King wrote:
>
> Does this mean that in arch/arm/mm/consistent.c, we should also set
> __GFP_COMP ? Should we be doing that today?
No, I don't believe so. I notice there's use of PageReserved and page
count manipulation in there, which we may well want to rationalize in
a later phase, perhaps replacing by __GFP_COMP then; but I don't see
any need to change what you're doing at this stage.
Looking again, to see why you even thought you might need to change:
the vital thing you're doing (aside from the PageReserved, which is
becoming irrelevant), which is missing from the regular high-order
allocation, is the set_page_count(page, 1). That's why you don't
need to change: the problems I was writing of come from when the
0-order page count goes down to 0.
Makes me wonder whether there could be a useful halfway stage to
compound pages, whether it would help for the page allocator to
set those counts to 1 generally.
Hugh
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
Register for a JBoss Training Course. Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
WARNING: multiple messages have this Message-ID (diff)
From: Hugh Dickins <hugh@veritas.com>
To: Russell King <rmk+lkml@arm.linux.org.uk>
Cc: Takashi Iwai <tiwai@suse.de>, Lee Revell <rlrevell@joe-job.com>,
Miles Lane <miles.lane@gmail.com>, Andrew Morton <akpm@osdl.org>,
LKML <linux-kernel@vger.kernel.org>,
alsa-devel <alsa-devel@lists.sourceforge.net>
Subject: Re: 2.6.15-rc1-mm2 -- Bad page state at free_hot_cold_page (in process 'aplay', page c18eef30)
Date: Mon, 21 Nov 2005 16:51:14 +0000 (GMT) [thread overview]
Message-ID: <Pine.LNX.4.61.0511211634440.16632@goblin.wat.veritas.com> (raw)
In-Reply-To: <20051121155239.GC21032@flint.arm.linux.org.uk>
On Mon, 21 Nov 2005, Russell King wrote:
>
> Does this mean that in arch/arm/mm/consistent.c, we should also set
> __GFP_COMP ? Should we be doing that today?
No, I don't believe so. I notice there's use of PageReserved and page
count manipulation in there, which we may well want to rationalize in
a later phase, perhaps replacing by __GFP_COMP then; but I don't see
any need to change what you're doing at this stage.
Looking again, to see why you even thought you might need to change:
the vital thing you're doing (aside from the PageReserved, which is
becoming irrelevant), which is missing from the regular high-order
allocation, is the set_page_count(page, 1). That's why you don't
need to change: the problems I was writing of come from when the
0-order page count goes down to 0.
Makes me wonder whether there could be a useful halfway stage to
compound pages, whether it would help for the page allocator to
set those counts to 1 generally.
Hugh
next prev parent reply other threads:[~2005-11-21 16:51 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-20 6:56 2.6.15-rc1-mm2 -- Bad page state at free_hot_cold_page (in process 'aplay', page c18eef30) Miles Lane
2005-11-20 8:05 ` Hugh Dickins
2005-11-20 18:14 ` Lee Revell
2005-11-20 18:14 ` Lee Revell
2005-11-20 19:35 ` Hugh Dickins
2005-11-21 6:59 ` Miles Lane
2005-11-21 6:59 ` Miles Lane
2005-11-21 11:52 ` Takashi Iwai
2005-11-21 15:46 ` Hugh Dickins
2005-11-21 15:52 ` Russell King
2005-11-21 16:51 ` Hugh Dickins [this message]
2005-11-21 16:51 ` Hugh Dickins
2005-11-21 16:17 ` Takashi Iwai
2005-11-21 16:25 ` Russell King
2005-11-21 16:41 ` Takashi Iwai
2005-11-21 17:09 ` Hugh Dickins
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=Pine.LNX.4.61.0511211634440.16632@goblin.wat.veritas.com \
--to=hugh@veritas.com \
--cc=akpm@osdl.org \
--cc=alsa-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=miles.lane@gmail.com \
--cc=rlrevell@joe-job.com \
--cc=rmk+lkml@arm.linux.org.uk \
--cc=tiwai@suse.de \
/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.