From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <410DCEBC.8030600@kolivas.org> Date: Mon, 02 Aug 2004 15:18:52 +1000 From: Con Kolivas MIME-Version: 1.0 Subject: Re: [PATCH] token based thrashing control References: <20040801175618.711a3aac.akpm@osdl.org> <410DAC89.4000002@kolivas.org> <410DCD84.2070707@kolivas.org> In-Reply-To: <410DCD84.2070707@kolivas.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDDAD4F44AF32328151427E49" Sender: owner-linux-mm@kvack.org Return-Path: To: Con Kolivas Cc: Rik van Riel , Andrew Morton , linux-mm@kvack.org, sjiang@cs.wm.edu, linux-kernel@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDDAD4F44AF32328151427E49 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Con Kolivas wrote: > 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. Or take that concept even further; Give them an absolute refractory period where they cannot take the token again and a relative refractory bit which can only be reset after the refractory period is over. Con --------------enigDDAD4F44AF32328151427E49 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBDc68ZUg7+tp6mRURAsjMAKCHVB0gvjtC9ZIU00SIfdKvawD8kwCeKxSp CY3PgDqv5FgLbO0/S+cqiP4= =5mha -----END PGP SIGNATURE----- --------------enigDDAD4F44AF32328151427E49-- -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: aart@kvack.org