public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: FabF <fabian.frederick@skynet.be>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Con Kolivas <kernel@kolivas.org>, Andrew Morton <akpm@osdl.org>,
	nigelenki@comcast.net, linux-kernel@vger.kernel.org
Subject: Re: Autoregulate swappiness & inactivation
Date: Fri, 09 Jul 2004 13:14:06 +0200	[thread overview]
Message-ID: <1089371646.3322.38.camel@localhost.localdomain> (raw)
In-Reply-To: <40EE76CC.5070905@yahoo.com.au>

On Fri, 2004-07-09 at 12:43, Nick Piggin wrote:
> FabF wrote:
> 
> > 
> > Here's an easy benchmark to demonstrate problem :
> > 1.Run Mozilla
> > 2.Minimize
> > 3=>Mozilla Resident Size (mrs) : 24Mb
> > 4.Run updatedb
> > 5.=>mrs : 15Mb
> > 6.updatedb ends up
> > 7.mrs doesn't move at all (yes, it goes down as I'm typing this msg :)).
> > 
> 
> How much RAM do you have? Does this happen with and without Con's
> patch?
Hi Nick,

256Mb with Con's patch 1 (autoswappiness activated) mm6
but it's general behaviour on my box :(

> 
> I don't have a problem here with your problem, however I'm running
> my -np patchset, which has different use-once heuristics.
> 
> > So my question is :
> > Don't we have a way to say "whose pages were reclaimed from and
> >  reattribute its" ? (having in mind memory status per se).
> > IOW flushing (I guess it's pdflush relevant ? ) do work for dead
> > processes but doesn't care about applications alive...
> > 
> 
> Page reclaim doesn't really know or care about processes, it
> basically works on a global page pool.
That's exactly the nerve center of the problem I guess.
When we swap we don't care about different processes but when some of
its is going in, we _quickly_ need to refresh memory but isn't it too
late ? I mean what do we do here ? We recover pages and "get application
to life".Desktop side of the story reminds me about some oses giving
_impression_ all was alright.I mean there must be a way to anticipate
 such trouble without renice -xx all GUI relevant processes
 in order to have both server/client cfg synergy.
 
> 
> pdflush is used to perform writeout of dirty data, so it has
> no part in reducing Mozilla's RSS.
Oops ... kswapd then ?

> 
> I don't really understand what you are asking though. Your basic
> problem is that mozilla's resident memory gets evicted too easily,
> is that right?
> 
Not at all.My problem is mozilla has some MB to recover when
reactivating; meanwhile, I consider there was sufficient resource to
share with it _before_ reactivation as I'm waiting some minutes after an
heavy process (e.g updatedb) to be done and over.

AFAICS, Con's patches are about auto-regulation, not about anticipation
(?)

Regards,
FabF



  reply	other threads:[~2004-07-09 11:14 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-07 15:16 2.6.7-ck5 Con Kolivas
2004-07-07 15:39 ` 2.6.7-ck5 John Richard Moser
2004-07-07 15:47   ` 2.6.7-ck5 Con Kolivas
2004-07-07 15:53     ` 2.6.7-ck5 Prakash K. Cheemplavam
2004-07-07 16:11       ` 2.6.7-ck5 P
2004-07-07 17:10         ` 2.6.7-ck5 Prakash K. Cheemplavam
2004-07-07 16:17       ` 2.6.7-ck5 Redeeman
2004-07-08  4:38     ` 2.6.7-ck5 Andrew Morton
2004-07-08  6:40       ` [PATCH] Autoregulate swappiness & inactivation Con Kolivas
2004-07-08  6:45         ` Con Kolivas
2004-07-08  7:06         ` [PATCH] " Nick Piggin
2004-07-08  7:12           ` Con Kolivas
2004-07-08  7:31             ` Nick Piggin
2004-07-08  8:03               ` Con Kolivas
2004-07-08  8:12                 ` Nick Piggin
2004-07-08 17:06                   ` John Richard Moser
2004-07-08 17:14                   ` [ck] " Mikhail Ramendik
2004-07-08 17:10           ` [ck] Re: [PATCH] " Mikhail Ramendik
2004-07-09  1:03             ` Nick Piggin
2004-07-08  7:10         ` Andrew Morton
2004-07-08  7:58           ` Con Kolivas
2004-07-08  8:08             ` Andrew Morton
2004-07-08  8:27               ` Con Kolivas
2004-07-08 10:54                 ` FabF
2004-07-09  1:05                   ` Con Kolivas
2004-07-09  9:48                     ` FabF
2004-07-09 10:43                       ` Nick Piggin
2004-07-09 11:14                         ` FabF [this message]
2004-07-09 11:24                           ` Nick Piggin
2004-07-10  9:44                             ` FabF
     [not found]                               ` <40EFC076.9050504@yahoo.com.au>
2004-07-10 10:57                                 ` rss recovery FabF
2004-07-10 12:03                                   ` Nick Piggin
2004-07-13 13:12                                     ` FabF
2004-07-08 16:26                 ` Autoregulate swappiness & inactivation Timothy Miller
2004-07-08 17:12                   ` John Richard Moser
2004-07-08 18:37                     ` Timothy Miller
2004-07-08 21:40                       ` John Richard Moser
2004-07-09  7:44                     ` Felipe Alfaro Solana
2004-07-08 16:24               ` [PATCH] Autotune swappiness Con Kolivas
2004-07-08 16:44                 ` Andrew Morton
2004-07-09  0:39                   ` Con Kolivas
2004-07-09  1:19                     ` [ck] " Kerin Millar
2004-07-09 14:23                     ` Martin J. Bligh
2004-07-09 14:26                       ` Con Kolivas
2004-07-08 15:57       ` [ck] Re: 2.6.7-ck5 GSehp
2004-07-07 16:45 ` 2.6.7-ck5 John Richard Moser
2004-07-07 17:10   ` 2.6.7-ck5 Prakash K. Cheemplavam
2004-07-07 22:26 ` 2.6.7-ck5 Wes Janzen
2004-07-07 22:53   ` 2.6.7-ck5 Con Kolivas
  -- strict thread matches above, loose matches on Subject: below --
2000-01-01 17:31 Autoregulate swappiness & inactivation deepfire

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=1089371646.3322.38.camel@localhost.localdomain \
    --to=fabian.frederick@skynet.be \
    --cc=akpm@osdl.org \
    --cc=kernel@kolivas.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nickpiggin@yahoo.com.au \
    --cc=nigelenki@comcast.net \
    /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