All of lore.kernel.org
 help / color / mirror / Atom feed
From: Con Kolivas <conman@kolivas.net>
To: Andrew Morton <akpm@digeo.com>
Cc: linux kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: [BENCHMARK] 2.5.40-mm2 with contest
Date: Tue,  8 Oct 2002 11:41:12 +1000	[thread overview]
Message-ID: <1034041272.3da237b8b7908@kolivas.net> (raw)
In-Reply-To: <3DA233EC.1119CD7B@digeo.com>

Quoting Andrew Morton <akpm@digeo.com>:

> Con Kolivas wrote:
> > 
> > ...
> > -       swap_tendency = mapped_ratio / 2 + distress + vm_swappiness;
> > +       swap_tendency = mapped_ratio / 2 + distress ;
> > +       if (swap_tendency > 50){
> > +               if (vm_swappiness <= 990) vm_swappiness+=10;
> > +               }
> > +               else
> > +               if (vm_swappiness > 0) vm_swappiness--;
> > +       swap_tendency += (vm_swappiness / 10);
> >
> 
> heh, that could work.  So basically you're saying "the longer we're
> under swap stress, the more swappy we want to get".

Exactly, which made complete sense to me.

> 
> Problem is, users have said they don't want that.  They say that they
> want to copy ISO images about all day and not swap.  I think.

But do they really want that or do they think they want that without knowing the
consequences of such a setting?

> It worries me.  It means that we'll be really slow to react to sudden
> load swings, and it increases the complexity of the analysis and
> testing.  And I really do want to give the user a single knob,
> which has understandable semantics and for which I can feasibly test
> all operating regions.
> 
> I really, really, really, really don't want to get too fancy in there.

Well I made it as simple as I possibly could. It seems to do what they want (not
swappy) but not at the expense of making the machine never swapping when it
really needs to - and the performance seems to be better all round in real
usage. I guess the only thing is it isn't a fixed number... unless we set a
maximum swappiness level or... but then it starts getting unnecessarily
complicated with questionable benefits.

> I have changed this code a bit, and have added other things.  Mainly
> over on the writer throttling side, which tends to be the place where
> the stress comes from in the first place.

/me waits but is a little disappointed

Con

  reply	other threads:[~2002-10-08  1:35 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-07  3:21 [BENCHMARK] 2.5.40-mm2 with contest Con Kolivas
2002-10-07  7:38 ` Andrew Morton
2002-10-08  1:01   ` Con Kolivas
2002-10-08  1:25     ` Andrew Morton
2002-10-08  1:41       ` Con Kolivas [this message]
2002-10-10 17:40         ` Bill Davidsen
2002-10-10 23:17           ` Con Kolivas
2002-10-10 17:32       ` Bill Davidsen
2002-10-10 18:11         ` Andrew Morton
  -- strict thread matches above, loose matches on Subject: below --
2002-10-07 12:11 Ed Tomlinson

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=1034041272.3da237b8b7908@kolivas.net \
    --to=conman@kolivas.net \
    --cc=akpm@digeo.com \
    --cc=linux-kernel@vger.kernel.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 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.