linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Dave Hansen <haveblue@us.ibm.com>
To: Alok Mooley <rangdi@yahoo.com>
Cc: "Martin J. Bligh" <mbligh@aracnet.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	linux-mm <linux-mm@kvack.org>
Subject: Re: Active Memory Defragmentation: Our implementation & problems
Date: 04 Feb 2004 10:46:26 -0800	[thread overview]
Message-ID: <1075920386.27981.106.camel@nighthawk> (raw)
In-Reply-To: <20040204183334.60551.qmail@web9701.mail.yahoo.com>

On Wed, 2004-02-04 at 10:33, Alok Mooley wrote:
> > Instead of a daemon
> > > kicking in on a threshold  violation (as proposed
> > by Mr. Daniel
> > > Phillips), we intend to capture idle cpu cycles by
> > inserting a new
> > > process just above the idle process.  
>
> The flexibility & the various levels of aggressiveness
> are fine, but won't the daemon be running when some
> other process could well have been?

I don't think that's too much of a problem.  kswapd runs when something
else might have been, but it's there to *help*.  Your defragger is there
to make things run better, so it doesn't matter if it runs instead of
something else for a bit.  In fact, if I were you, I might just
integrate it into the current kswapd.  

> In this case, won't a process just above the idle
> process be a better proposition, since we know that
> the cpu is now truly idle? This may be at the cost of
> not having control over when this process is
> scheduled,if ever.

I don't think idleness is as big of a deal as you're making it out to
be.  You can always take a look at the load while you're about to start
and make a decision then.  

> If we do allow our preemption (before our work is well
> & truly finished), even a simple page-fault will wreak
> havoc, since it may change the memory state & we have
> to do the same work (gathering the new memory state)
> all over again. This becomes all the more significant
> considering that 2.6.0 is a preemptible kernel.
> Considering this, should we allow our preemption? If
> not, won't this hog the cpu? Is there any way out?

The "work until we get interrupted and restart if something changes
state" approach is very, very common.  Can you give some more examples
of just how a page fault would ruin the defrag process?

--dave

--
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: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

  reply	other threads:[~2004-02-04 18:46 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-03  4:46 Alok Mooley
2004-02-03 21:26 ` Dave Hansen
2004-02-03 22:26   ` Martin J. Bligh
2004-02-04  5:09   ` Alok Mooley
2004-02-04  5:24     ` Mike Fedyk
2004-02-04  5:54     ` Dave Hansen
2004-02-04  6:05       ` Martin J. Bligh
2004-02-04  6:22         ` Dave Hansen
2004-02-04  6:29           ` Martin J. Bligh
2004-02-04  6:40             ` Dave Hansen
2004-02-04  7:17               ` Martin J. Bligh
2004-02-04  8:30                 ` Andrew Morton
2004-02-04  6:53             ` Doubt about statm_pgd_range patch Arunkumar
2004-02-04  6:57       ` Active Memory Defragmentation: Our implementation & problems IWAMOTO Toshihiro
2004-02-04  7:10         ` Dave Hansen
2004-02-04  7:50           ` IWAMOTO Toshihiro
2004-02-04 10:33         ` Hirokazu Takahashi
2004-02-04 18:33       ` Alok Mooley
2004-02-04 18:46         ` Dave Hansen [this message]
2004-02-04 18:54           ` Alok Mooley
2004-02-04 19:07             ` Richard B. Johnson
2004-02-04 19:18               ` Alok Mooley
2004-02-04 19:33                 ` Richard B. Johnson
2004-02-05  5:07                   ` Alok Mooley
2004-02-05 19:03                   ` Pavel Machek
2004-02-04 19:35               ` Dave McCracken
2004-02-04 21:59                 ` Timothy Miller
2004-02-04 23:24                   ` Dave Hansen
2004-02-05 16:32                     ` Dave McCracken
2004-02-04 19:37               ` Timothy Miller
2004-02-04 19:43                 ` Dave Hansen
2004-02-04 19:59                 ` Richard B. Johnson
2004-02-04 19:56             ` Dave Hansen
2004-02-05  5:19               ` Alok Mooley
2004-02-04 20:12 Mark_H_Johnson

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=1075920386.27981.106.camel@nighthawk \
    --to=haveblue@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mbligh@aracnet.com \
    --cc=rangdi@yahoo.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox