From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1OxIfE-0008Ol-EQ for garchives@archives.gentoo.org; Sun, 19 Sep 2010 12:06:37 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 45FBEE05FE; Sun, 19 Sep 2010 12:06:16 +0000 (UTC) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by pigeon.gentoo.org (Postfix) with ESMTP id 23F32E05FE for ; Sun, 19 Sep 2010 12:06:16 +0000 (UTC) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id 052C0169; Sun, 19 Sep 2010 08:06:16 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Sun, 19 Sep 2010 08:06:16 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=message-id:date:from:reply-to:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; s=smtpout; bh=c5I2jxlpbhhWUpMAcpLlG7X41vM=; b=HT5FKv3hecoxymGCWSPTTdVUECWabZDD2Z01MqNRDo2zAQZ2UQIjDEioP2JeqSGjIitHC8LdxAZmGidO9SR8q+e1qIsTJeWUh8eEFfWjTiQGbsRphgEO0qlBJdiwNk4YngTT8vEMR5rUNeuOoYOlKnHMXDCeACySPWS4DKpqO6w= X-Sasl-enc: OGCSGcQER4C5sULzHFyaeUHT2vuvYed1z7ozsB1GKxZf 1284897975 Received: from [192.168.5.18] (lvps83-169-5-6.dedicated.hosteurope.de [83.169.5.6]) by mail.messagingengine.com (Postfix) with ESMTPSA id 305D6409141 for ; Sun, 19 Sep 2010 08:06:14 -0400 (EDT) Message-ID: <4C95FCB4.5020604@f_philipp.fastmail.net> Date: Sun, 19 Sep 2010 14:06:12 +0200 From: Florian Philipp User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.7) Gecko/20100808 Lightning/1.0b2pre Thunderbird/3.1.1 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] KDE ridiculous memory usage References: <4C94D075.6040508@f_philipp.fastmail.net> <201009191025.07004.alan.mckinnon@gmail.com> In-Reply-To: <201009191025.07004.alan.mckinnon@gmail.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: e877ccaa-06a4-4a1a-b45c-9951722b7ec7 X-Archives-Hash: 50ef05a71d5168f9a7a2b4690127eb88 Am 19.09.2010 10:25, schrieb Alan McKinnon: [...] > Like I posted in another thread today, the memory columns in top do not= mean=20 > what most people think they mean, nor are they simplistic. >=20 > The columns tell you the amount of memory that process can access. This= is=20 > vitally important to understand. Modern memory managers in all OSes hav= e the=20 > concept of shared code and shared memory. It would be insanely wasteful= for=20 > each process to have it's own copy of all the data in RAM it ever uses.= At a=20 > minimum, every process would need a full copy of glibc loaded into RAM. >=20 > Here's what really happens (simplistic version): >=20 > An app loads, and links to libraries it needs. They may or may not alre= ady be=20 > in RAM; if nor, they are loaded. Those binary images increase the amoun= t of=20 > RAM the process may address. The app uses more RAM for it's own purpose= s (data=20 > it is using) and after a while lots of that data is still in RAM but no= longer=20 > being used. >=20 > When things get tight, the kernel has a good long hard look at memory u= sage=20 > and starts chucking bits away that can be dispensed with safely. How mu= ch=20 > control do you, the user, have over this: none whatsoever. Why: because= the=20 > situation is changing millions of times a second and there's no way you= can=20 > keep up. >=20 > It's like your heart. You don't actually want to be bothered keeping th= e damn=20 > thing pumping consciously. So you let your brain stem do all that heavy= =20 > lifting. With memory, the kernel is your brain stem. >=20 > Your numbers above look perfectly normal. Most of that RAM can and will= be=20 > dumped when something else comes along that needs it. The clincher is y= our=20 > swap usage. After 8 days you are using only about 12% of total which in= dicates=20 > the kernel is quite happily keeping everything under control and still = has=20 > plenty of wiggle room left to keep you humming along nicely. >=20 > The only point where this memory scheme goes wrong is when an app has a= memory=20 > leak - it has finished with some data in RAM and does not release it. T= he=20 > chances that all your "memory hogs" all have leaks like this are very s= mall.=20 >=20 > Final conclusion: you have nothing to worry about. >=20 I disagree on that last point. While it might be true that some of the statistics are not correct, I have a feeling that it is not acceptable or normal that a simple desktop system is not able to free enough memory to have more that 1/8 of it available for cache. I mean, my old system had 2 GB RAM and an equivalent Gnome system on it. It needed swap as well due to Firefox and Eclipse eating memory. But otherwise its usage was far less than what I see here.