From: Con Kolivas <kernel@kolivas.org>
To: Nick Piggin <piggin@cyberone.com.au>
Cc: "Nakajima, Jun" <jun.nakajima@intel.com>,
linux kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] 2.6.0 batch scheduling, HT aware
Date: Tue, 23 Dec 2003 14:15:38 +1100 [thread overview]
Message-ID: <200312231415.38611.kernel@kolivas.org> (raw)
In-Reply-To: <3FE7AF24.40600@cyberone.com.au>
On Tue, 23 Dec 2003 13:57, Nick Piggin wrote:
> Con Kolivas wrote:
> >On Tue, 23 Dec 2003 12:36, Nick Piggin wrote:
> >>Con Kolivas wrote:
> >>>I discussed this with Ingo and that's the sort of thing we thought of.
> >>>Perhaps a relative crossover of 10 dynamic priorities and an absolute
> >>>crossover of 5 static priorities before things got queued together. This
> >>>is really only required for the UP HT case.
> >>
> >>Well I guess it would still be nice for "SMP HT" as well. Hopefully the
> >>code can be generic enough that it would just carry over nicely.
> >
> >I disagree. I can't think of a real world scenario where 2+ physical cpus
> >would benefit from this.
>
> Well its the same problem. A nice -20 process can still lose 40-55% of its
> performance to a nice 19 process, a figure of 10% is probably too high and
> we'd really want it <= 5% like what happens with a single logical
> processor.
I changed my mind just after I sent that mail. 4 physical cores running three
nice 20 and one nice -20 task gives the nice -20 task only 25% of the total
cpu and 25% to each of the nice 20 tasks.
> >>It does
> >>have complications though because the load balancer would have to be
> >> taught about it, and those architectures that do hardware priorities
> >> probably don't even want it.
> >
> >Probably the simple relative/absolute will have to suffice. However it
> > still doesn't help the fact that running something cpu bound concurrently
> > at nice 0 with something interactive nice 0 is actually slower if you use
> > a UP HT processor in SMP mode instead of UP.
>
> It will be based on dynamic priorities, possibly with some feedback from
> nice as well, but it probably still won't be perfect and it will probably
> be very complex *cough* hardware priorities *cough* ;)
>
> I might try to fit it into a more general priority balancing system because
> we currently have similar sorts of failings on regular SMP as well.
I'll keep my eyes peeled. Meanwhile I'll use my ugly patch ;-)
Con
next prev parent reply other threads:[~2003-12-23 3:15 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-12-23 0:38 [PATCH] 2.6.0 batch scheduling, HT aware Con Kolivas
2003-12-23 1:11 ` Nick Piggin
2003-12-23 1:24 ` Con Kolivas
2003-12-23 1:36 ` Nick Piggin
2003-12-23 2:42 ` Con Kolivas
2003-12-23 2:57 ` Nick Piggin
2003-12-23 3:15 ` Con Kolivas [this message]
2003-12-23 3:16 ` Con Kolivas
2003-12-26 23:03 ` Pavel Machek
2003-12-23 15:51 ` bill davidsen
2003-12-23 22:09 ` Con Kolivas
2003-12-30 0:35 ` bill davidsen
2004-01-02 20:10 ` Bill Davidsen
2003-12-26 22:56 ` Pavel Machek
2003-12-26 23:42 ` Con Kolivas
2003-12-26 23:49 ` Con Kolivas
2003-12-27 11:09 ` Pavel Machek
2003-12-27 11:15 ` Con Kolivas
2003-12-30 0:29 ` bill davidsen
2003-12-29 7:02 ` Nick Piggin
2003-12-29 12:49 ` Pavel Machek
2003-12-27 8:52 ` Mika Penttilä
2003-12-30 0:32 ` bill davidsen
2004-01-02 20:05 ` Bill Davidsen
2004-01-02 20:56 ` Davide Libenzi
2004-01-02 21:10 ` Valdis.Kletnieks
2004-01-02 23:34 ` Davide Libenzi
-- strict thread matches above, loose matches on Subject: below --
2003-12-23 1:59 Nakajima, Jun
2003-12-23 2:40 ` Nick Piggin
2003-12-23 5:33 Nakajima, Jun
2003-12-23 10:13 ` Nick Piggin
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=200312231415.38611.kernel@kolivas.org \
--to=kernel@kolivas.org \
--cc=jun.nakajima@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=piggin@cyberone.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.