public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Con Kolivas <kernel@kolivas.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: linux kernel mailing list <linux-kernel@vger.kernel.org>,
	Jos Hulzink <josh@stack.nl>
Subject: Re: [PATCH] 2.6.1 Hyperthread smart "nice" 2
Date: Tue, 3 Feb 2004 21:52:46 +1100	[thread overview]
Message-ID: <200402032152.46481.kernel@kolivas.org> (raw)
In-Reply-To: <20040202103122.GA29402@elte.hu>

On Mon, 2 Feb 2004 21:31, Ingo Molnar wrote:
> * Con Kolivas <kernel@kolivas.org> wrote:
> > What this one does is the following; If there is a "nice" difference
> > between tasks running on logical cores of the same cpu, the more
> > "nice" one will run a proportion of time equal to the timeslice it
> > would have been given relative to the less "nice" task.  ie a nice 19
> > task running on one core and the nice 0 task running on the other core
> > will let the nice 0 task run continuously (102ms is normal timeslice)
> > and the nice 19 task will only run for the last 10ms of time the nice
> > 0 task is running. This makes for a much more balanced resource
> > distribution, gives significant preference to the higher priority
> > task, but allows them to benefit from running on both logical cores.
>
> this is a really good rule conceptually - the higher prio task will get
> at least as much raw (unshared) physical CPU slice as it would get
> without HT.

Glad you agree.

>From the anandtech website a description of the P4 Prescott (next generation 
IA32) with hyperthreading shows this with the new SSE3 instruction set:

"Finally we have the two thread synchronization instructions – monitor and 
mwait. These two instructions work hand in hand to improve Hyper Threading 
performance. The instructions work by determining whether a thread being sent 
to the core is the OS’ idle thread or other non-productive threads generated 
by device drivers and then instructing the core to worry about those threads 
after working on whatever more useful thread it is working on at the time."

At least it appears Intel are well aware of the priority problem, but full 
priority support across logical cores is not likely. However I guess these 
new instructions are probably enough to work with if someone can do the 
coding.

Con

  reply	other threads:[~2004-02-03 10:53 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-29  8:17 [PATCH] 2.6.1 Hyperthread smart "nice" Con Kolivas
2004-01-29  9:39 ` Jos Hulzink
2004-01-29 10:28   ` Con Kolivas
2004-01-29 10:36     ` Con Kolivas
2004-02-02  9:27   ` [PATCH] 2.6.1 Hyperthread smart "nice" 2 Con Kolivas
2004-02-02 10:31     ` Ingo Molnar
2004-02-03 10:52       ` Con Kolivas [this message]
2004-02-03 10:58         ` Ingo Molnar
2004-02-03 11:07           ` Con Kolivas
2004-02-03 11:12             ` Ingo Molnar
2004-02-03 11:14               ` Con Kolivas
2004-02-03 11:47                 ` Ingo Molnar
2004-02-03 11:19             ` Nick Piggin
2004-02-03 22:59           ` Andrew Morton

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=200402032152.46481.kernel@kolivas.org \
    --to=kernel@kolivas.org \
    --cc=josh@stack.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /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