From: Andrea Arcangeli <andrea@suse.de>
To: Kanoj Sarcar <kanoj@google.engr.sgi.com>
Cc: Ingo Molnar <mingo@elte.hu>, Hubertus Franke <frankeh@us.ibm.com>,
Mike Kravetz <mkravetz@sequent.com>,
Fabio Riccardi <fabio@chromium.com>,
Linux Kernel List <linux-kernel@vger.kernel.org>,
lse-tech@lists.sourceforge.net
Subject: Re: [Lse-tech] Re: a quest for a better scheduler
Date: Wed, 4 Apr 2001 20:00:37 +0200 [thread overview]
Message-ID: <20010404200037.S20911@athlon.random> (raw)
In-Reply-To: <20010404191604.O20911@athlon.random> <200104041749.KAA74097@google.engr.sgi.com>
In-Reply-To: <200104041749.KAA74097@google.engr.sgi.com>; from kanoj@google.engr.sgi.com on Wed, Apr 04, 2001 at 10:49:04AM -0700
On Wed, Apr 04, 2001 at 10:49:04AM -0700, Kanoj Sarcar wrote:
> Imagine that most of the program's memory is on node 1, it was scheduled
> on node 2 cpu 8 momentarily (maybe because kswapd ran on node 1, other
> higher priority processes took over other cpus on node 1, etc).
>
> Then, your patch will try to keep the process on node 2, which is not
> neccessarily the best solution. Of course, as I mentioned before, if
> you have a node local cache on node 2, that cache might have been warmed
> enough to make scheduling on node 2 a good option.
Exactly it made it a good option, and more important this heuristic can
only improve performance if compared to the mainline scheduler.
Infact I tried to reschedule the task back to its original node and it dropped
performance, anyways I cannot say to have done an extensive research on that, I
believe if we take care of some more history of the node migration we may
understand it's right time to push it back to its original node but that was
not obvious and I wanted a simple solution to boost the performance under CPU
bound load to start with.
Andrea
next prev parent reply other threads:[~2001-04-04 18:03 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-04-04 13:43 a quest for a better scheduler Hubertus Franke
2001-04-04 13:25 ` Ingo Molnar
2001-04-04 13:34 ` Ingo Molnar
2001-04-04 15:08 ` Andrea Arcangeli
2001-04-04 16:50 ` [Lse-tech] " Kanoj Sarcar
2001-04-04 17:16 ` Andrea Arcangeli
2001-04-04 17:49 ` Kanoj Sarcar
2001-04-04 18:00 ` Andrea Arcangeli [this message]
2001-04-05 11:13 ` Zdenek Kabelac
2001-04-04 16:39 ` Kanoj Sarcar
2001-04-04 17:00 ` Andrea Arcangeli
2001-04-04 15:44 ` Khalid Aziz
2001-04-04 15:55 ` [Lse-tech] " Christoph Hellwig
-- strict thread matches above, loose matches on Subject: below --
2001-04-04 17:03 Hubertus Franke
2001-04-04 17:14 ` Kanoj Sarcar
2001-04-04 17:34 Hubertus Franke
2001-04-04 17:40 Paul McKenney
2001-04-05 11:14 alad
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=20010404200037.S20911@athlon.random \
--to=andrea@suse.de \
--cc=fabio@chromium.com \
--cc=frankeh@us.ibm.com \
--cc=kanoj@google.engr.sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lse-tech@lists.sourceforge.net \
--cc=mingo@elte.hu \
--cc=mkravetz@sequent.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