From: Davide Libenzi <davidel@xmailserver.org>
To: Hubertus Franke <frankeh@us.ibm.com>
Cc: lse-tech@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Re: CPU affinity & IPI latency
Date: Mon, 16 Jul 2001 09:16:50 -0700 (PDT) [thread overview]
Message-ID: <XFMail.20010716091650.davidel@xmailserver.org> (raw)
In-Reply-To: <OFE9275D2B.C8E7F6FC-ON85256A8B.00370192@pok.ibm.com>
On 16-Jul-2001 Hubertus Franke wrote:
>
> David, you are preaching to choir.
>
> One can not have it both ways, at least without "#ifdef"s.
> As Mike stated, we made the decision to adhere to current scheduling
> semantics
> purely for the purspose of comparision and increased adaptation chances.
> As shown with the LoadBalancing addition to MQ, there are simple ways to
> relax and completely eliminate the feedback between the queues, if one so
> desires.
>
> As for the solutions you proposed for the "switching problem", namely the
> wakeup
> list. I don't think you want a list here. A list would basically mean that
> you
> would need to walk it and come up with a single decision again. I think
> what
> I proposed, namely a per-CPU reschedule reservation that can be overwritten
> taking
> PROC_CHANGE_PENALTY or some form of it into account, seems a better
> solution.
> Open to discussions...
No, when you're going to decide ( reschedule_idle ) which idle to spin out, you
can inspect the wake list and, based on the content of the list, one can take a
better decision about which idle to wake.
I think that a list, instead of a single task pointer, is a more open solution
that could drive to a more sophisticated choice of the CPU to stock the task to.
- Davide
next prev parent reply other threads:[~2001-07-16 16:13 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-07-16 10:10 CPU affinity & IPI latency Hubertus Franke
2001-07-16 16:16 ` Davide Libenzi [this message]
-- strict thread matches above, loose matches on Subject: below --
2001-07-16 21:45 Hubertus Franke
2001-07-16 22:56 ` Davide Libenzi
2001-07-16 18:26 Hubertus Franke
2001-07-14 3:25 Hubertus Franke
2001-07-16 16:14 ` Mike Kravetz
2001-07-16 21:25 ` Davide Libenzi
2001-07-12 23:40 Mike Kravetz
2001-07-13 0:22 ` Davide Libenzi
2001-07-13 0:36 ` Larry McVoy
2001-07-13 2:06 ` Mark Hahn
2001-07-13 16:41 ` Davide Libenzi
2001-07-13 17:31 ` Mike Kravetz
2001-07-13 19:17 ` Davide Libenzi
2001-07-13 17:05 ` Mike Kravetz
2001-07-13 19:51 ` David Lang
2001-07-13 22:43 ` Mike Kravetz
2001-07-15 20:02 ` Davide Libenzi
2001-07-15 20:15 ` Andi Kleen
2001-07-15 20:31 ` Davide Libenzi
2001-07-13 19:54 ` Chris Wedgwood
2001-07-15 7:42 ` Troy Benjegerdes
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=XFMail.20010716091650.davidel@xmailserver.org \
--to=davidel@xmailserver.org \
--cc=frankeh@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lse-tech@lists.sourceforge.net \
/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.