All of lore.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 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.