From: Rohit Seth <rohit.seth@intel.com>
To: "Martin J. Bligh" <mbligh@mbligh.org>
Cc: Andrew Morton <akpm@osdl.org>, Mattia Dongili <malattia@linux.it>,
linux-kernel@vger.kernel.org
Subject: Re: 2.6.14-rc2-mm1
Date: Tue, 27 Sep 2005 13:05:02 -0700 [thread overview]
Message-ID: <1127851502.6144.10.camel@akash.sc.intel.com> (raw)
In-Reply-To: <922980000.1127847470@flay>
On Tue, 2005-09-27 at 11:57 -0700, Martin J. Bligh wrote:
> > Seems like from the log messages that quite a few pages are hanging
> in the cpu's cold pcp list even with the low memory conditions. Below
> is the patch to reduce the higher bound in cold pcp list (...this got
> increased with my previous change).
>
> >
> > I think we should also drain the CPU's hot and cold pcps for the
> GFP_KERNEL page requests (in the event the higher order request is not
> able to get serviced otherwise). This will still only drains the
> current CPUs pcps in an MP environment (leaving the other CPUs with
> their lists intact). I will send this patch later today.
>
> >
> > [PATCH]: Reduce the high mark in cpu's cold pcp list.
> >
> > Signed-off-by: Rohit Seth <rohit.seth@intel.com>
> >
> >
> > --- linux-2.6.13.old/mm/page_alloc.c 2005-09-26 10:57:07.000000000
> -0700
> > +++ linux-2.6.13.work/mm/page_alloc.c 2005-09-26 10:47:57.000000000
> -0700
> > @@ -1749,7 +1749,7 @@
> > pcp = &p->pcp[1]; /* cold*/
> > pcp->count = 0;
> > pcp->low = 0;
> > - pcp->high = 2 * batch;
> > + pcp->high = batch / 2;
> > pcp->batch = max(1UL, batch/2);
> > INIT_LIST_HEAD(&pcp->list);
> > }
> > -
>
> I don't understand. How can you set the high watermark at half the
> batch size? Makes no sense to me.
>
The batch size for the cold pcp list is getting initialized to batch/2
in the code snip above. So, this change is setting the high water mark
for cold list to same as pcp's batch number.
> And can you give a stricter definiton of what you mean by "low memory
> conditions"? I agree we ought to empty the lists before going OOM or
> anything, but not at the slightest feather of pressure ... answer lies
> somewhere inbetween ... but where?
>
In the specific case of dump information that Mattia sent earlier, there
is only 4M of free mem available at the time the order 1 request is
failing.
In general, I think if a specific higher order ( > 0) request fails that
has GFP_KERNEL set then at least we should drain the pcps.
-rohit
next prev parent reply other threads:[~2005-09-27 19:57 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-22 5:28 2.6.14-rc2-mm1 Andrew Morton
2005-09-22 6:35 ` 2.6.14-rc2-mm1 Joel Becker
2005-09-22 6:46 ` 2.6.14-rc2-mm1 Reuben Farrelly
2005-09-22 7:03 ` 2.6.14-rc2-mm1 Andrew Morton
2005-09-22 18:59 ` 2.6.14-rc2-mm1 Martin J. Bligh
2005-09-22 19:52 ` 2.6.14-rc2-mm1 Andrew Morton
2005-09-22 20:14 ` 2.6.14-rc2-mm1 Martin J. Bligh
2005-09-23 0:28 ` 2.6.14-rc2-mm1 Martin J. Bligh
2005-09-22 22:28 ` 2.6.14-rc2-mm1 - ide problems ? Badari Pulavarty
2005-09-22 23:39 ` Andrew Morton
2005-09-22 19:50 ` tty update speed regression (was: 2.6.14-rc2-mm1) Alexey Dobriyan
2005-09-22 21:49 ` Alexey Dobriyan
2005-09-23 0:08 ` Nishanth Aravamudan
2005-09-23 17:12 ` Nish Aravamudan
2005-09-23 18:42 ` Alexey Dobriyan
2005-09-23 19:07 ` Nishanth Aravamudan
2005-09-23 19:42 ` Alexey Dobriyan
2005-09-23 21:32 ` Nishanth Aravamudan
2005-09-24 17:43 ` 2.6.14-rc2-mm1 Mattia Dongili
2005-09-24 17:58 ` 2.6.14-rc2-mm1 Mattia Dongili
2005-09-24 18:23 ` 2.6.14-rc2-mm1 Andrew Morton
2005-09-26 19:33 ` 2.6.14-rc2-mm1 Seth, Rohit
2005-09-27 18:57 ` 2.6.14-rc2-mm1 Martin J. Bligh
2005-09-27 20:05 ` Rohit Seth [this message]
2005-09-27 21:18 ` 2.6.14-rc2-mm1 Martin J. Bligh
2005-09-27 21:51 ` 2.6.14-rc2-mm1 Rohit Seth
2005-09-27 21:59 ` 2.6.14-rc2-mm1 Martin J. Bligh
2005-09-27 22:49 ` 2.6.14-rc2-mm1 Rohit Seth
2005-09-27 22:49 ` 2.6.14-rc2-mm1 Martin J. Bligh
2005-09-27 23:16 ` 2.6.14-rc2-mm1 Rohit Seth
2005-09-27 7:13 ` 2.6.14-rc2-mm1 (Oops, possibly Netfilter related?) Reuben Farrelly
2005-09-27 7:44 ` Andrew Morton
2005-09-27 18:59 ` Martin J. Bligh
2005-10-02 17:13 ` Paul Jackson
2005-10-02 21:31 ` Martin J. Bligh
2005-10-03 17:20 ` Rohit Seth
2005-10-03 17:56 ` Martin J. Bligh
-- strict thread matches above, loose matches on Subject: below --
2005-09-25 22:00 2.6.14-rc2-mm1 Paul Blazejowski
2005-09-25 23:44 ` 2.6.14-rc2-mm1 Andrew Morton
2005-09-26 4:32 ` 2.6.14-rc2-mm1 Carlo Calica
2005-09-28 4:56 ` 2.6.14-rc2-mm1 Paul Blazejowski
2005-09-28 19:07 ` 2.6.14-rc2-mm1 Carlo Calica
2005-09-26 7:14 ` 2.6.14-rc2-mm1 Tim Schmielau
2005-09-28 5:01 ` 2.6.14-rc2-mm1 Paul Blazejowski
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=1127851502.6144.10.camel@akash.sc.intel.com \
--to=rohit.seth@intel.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=malattia@linux.it \
--cc=mbligh@mbligh.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox