All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bill Davidsen <davidsen@tmr.com>
To: linux-kernel@vger.kernel.org
Subject: Re: Gigantic memory leak in linux-2.6.[789]!
Date: Sun, 24 Oct 2004 10:14:36 -0400	[thread overview]
Message-ID: <clgc6m$u72$1@gatekeeper.tmr.com> (raw)
In-Reply-To: <Pine.LNX.4.60.0410221743590.20604@dlang.diginsite.com>

David Lang wrote:

> This puts the cost of zeroing out and freeing memory on new programs 
> that are allocating memory, which tends to scatter the work over time 
> rather then having a large burst of work kick in when a program exits 
> (it seems odd to think that if a large computer exits the machine would 
> be pegged for a little while while it frees up and zeros the memory, not 
> exactly what you would expect when you killed a program :-)

Any this partially explains why response is bad every morning when 
starting daily operation. Instead of using the totally unproductive time 
in the idle loop to zero and free those pages when it would not hurt 
response, the kernel saves that work for the next time the memory is 
needed lest it do work which might not be needed before the system is 
shutdown.

With all the work Nick, Ingo,Con and others are putting into latency and 
responsiveness, I don't understand why anyone thinks this is desirable 
behavior. The idle loop is the perfect place to perform things like 
this, to convert non-productive cycles into performing tasks which will 
directly improve response and performance when the task MUST be done. 
Things like zeroing these pages, perhaps defragmenting memory, anything 
which can be done in small parts.

It would seem that doing things like this in small inefficient steps in 
idle moments is still better than doing them efficiently while a process 
is waiting for the resources being freed.

-- 
bill davidsen <davidsen@tmr.com>
   CTO TMR Associates, Inc
   Doing interesting things with small computers since 1979

  reply	other threads:[~2004-10-24 14:02 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-22 14:13 Gigantic memory leak in linux-2.6.[789]! Kristian Sørensen
2004-10-22 14:32 ` Kasper Sandberg
2004-10-22 15:07   ` Richard B. Johnson
2004-10-22 15:50     ` Kristian Sørensen
2004-10-22 16:12       ` Richard B. Johnson
2004-10-22 19:24         ` Kristian Sørensen
2004-10-22 19:20           ` Richard B. Johnson
2004-10-22 19:33           ` Chris Friesen
2004-10-22 16:15     ` Gene Heskett
2004-10-22 16:28       ` Andre Tomt
2004-10-22 16:32       ` Chris Friesen
2004-10-23  0:51 ` David Lang
2004-10-24 14:14   ` Bill Davidsen [this message]
2004-10-24 16:04     ` Tommy Reynolds
2004-10-25 22:11       ` Bill Davidsen
2004-10-25 22:47     ` David Lang
2004-10-23  1:44 ` Bernd Eckenfels

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='clgc6m$u72$1@gatekeeper.tmr.com' \
    --to=davidsen@tmr.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.