From: Andrew Theurer <habanero@us.ibm.com>
To: mingo@elte.hu, nickpiggin@yahoo.com.au, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/13] timestamp fixes
Date: Mon, 28 Feb 2005 12:11:18 -0600 [thread overview]
Message-ID: <42235EC6.9030900@us.ibm.com> (raw)
In-Reply-To: <42235517.5070504@us.ibm.com>
Nick, can you describe the system you run the DB tests on? Do you have
any cpu idle time stats and hopefully some context switch rate stats?
I think I understand the concern [patch 6] of stealing a task from one
node to an idle cpu in another node, but I wonder if we can have some
sort of check for idle balance: if the domain/node to steal from has
some idle cpu somewhere, we do not steal, period. To do this we have a
cpu_idle bitmask, we update as cpus go idle/busy, and we reference this
cpu_idle & sd->cpu_mask to see if there's at least one cpu that's idle.
> Ingo wrote:
>
> But i expect fork/clone balancing to be almost certainly a problem. (We
> didnt get it right for all workloads in 2.6.7, and i think it cannot be
> gotten right currently either, without userspace API help - but i'd be
> happy to be proven wrong.)
Perhaps initially one could balance on fork up to the domain level which
has task_hot_time=0, up to a shared cache by default. Anything above
that could require a numactl like preference from userspace.
-Andrew Theurer
next parent reply other threads:[~2005-02-28 18:11 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <42235517.5070504@us.ibm.com>
2005-02-28 18:11 ` Andrew Theurer [this message]
2005-03-01 8:09 ` [PATCH 1/13] timestamp fixes Nick Piggin
2005-03-01 9:03 ` Nick Piggin
2005-02-24 7:14 [PATCH 0/13] Multiprocessor CPU scheduler patches Nick Piggin
2005-02-24 7:16 ` [PATCH 1/13] timestamp fixes Nick Piggin
2005-02-24 7:46 ` Ingo Molnar
2005-02-24 7:56 ` Nick Piggin
2005-02-24 8:34 ` Ingo Molnar
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=42235EC6.9030900@us.ibm.com \
--to=habanero@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=nickpiggin@yahoo.com.au \
/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.