public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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



  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