All of lore.kernel.org
 help / color / mirror / Atom feed
From: Con Kolivas <kernel@kolivas.org>
To: Rik van Riel <riel@redhat.com>
Cc: Andrew Morton <akpm@osdl.org>,
	linux-mm@kvack.org, sjiang@cs.wm.edu,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] token based thrashing control
Date: Mon, 02 Aug 2004 15:13:40 +1000	[thread overview]
Message-ID: <410DCD84.2070707@kolivas.org> (raw)
In-Reply-To: <Pine.LNX.4.58.0408012332080.13053@dhcp030.home.surriel.com>

[-- Attachment #1: Type: text/plain, Size: 1087 bytes --]

Rik van Riel wrote:
> On Mon, 2 Aug 2004, Con Kolivas wrote:
> 
> 
>>We have some results that need interpreting with contest.
>>mem_load:
>>Kernel    [runs]	Time	CPU%	Loads	LCPU%	Ratio
>>2.6.8-rc2      4	78	146.2	94.5	4.7	1.30
>>2.6.8-rc2t     4	318	40.9	95.2	1.3	5.13
>>
>>The "load" with mem_load is basically trying to allocate 110% of free 
>>ram, so the number of "loads" although similar is not a true indication 
>>of how much ram was handed out to mem_load. What is interesting is that 
>>since mem_load runs continuously and constantly asks for too much ram it 
>>seems to be receiving the token most frequently in preference to the cc 
>>processes which are short lived. I'd say it is quite hard to say 
>>convincingly that this is bad because the point of this patch is to 
>>prevent swap thrash.
> 
> 
> It may be worth trying with a shorter token timeout
> time - maybe even keeping the long ineligibility ?

Give them a "refractory" bit which is set if they take the token? Next 
time they try to take the token unset the refractory bit instead of 
taking the token.

Con

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

  reply	other threads:[~2004-08-02  5:14 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-30 21:37 [PATCH] token based thrashing control Rik van Riel
2004-07-31  3:35 ` jhigdon
2004-07-31 11:34 ` Nikita Danilov
2004-07-31 11:43   ` Rik van Riel
2004-08-01 11:05 ` Andrew Morton
2004-08-01 11:13   ` Arjan van de Ven
2004-08-01 21:52   ` Rik van Riel
2004-08-01 13:02 ` Rik van Riel
2004-08-01 13:02   ` Rik van Riel
2004-08-02  0:56   ` Andrew Morton
2004-08-02  0:56     ` Andrew Morton
2004-08-02  1:36     ` Rik van Riel
2004-08-02  1:36       ` Rik van Riel
2004-08-02  2:52     ` Con Kolivas
2004-08-02  3:33       ` Rik van Riel
2004-08-02  3:33         ` Rik van Riel
2004-08-02  5:13         ` Con Kolivas [this message]
2004-08-02  5:18           ` Con Kolivas
2004-08-03  0:34             ` Song Jiang
2004-08-03  0:34               ` Song Jiang
2004-08-03  1:20               ` Rik van Riel
2004-08-03  1:20                 ` Rik van Riel
2004-08-04  4:51                 ` Song Jiang
2004-08-04  4:51                   ` Song Jiang
2004-08-04 11:30                   ` Rik van Riel
2004-08-04 11:30                     ` Rik van Riel

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=410DCD84.2070707@kolivas.org \
    --to=kernel@kolivas.org \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=riel@redhat.com \
    --cc=sjiang@cs.wm.edu \
    /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.