public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Con Kolivas <kernel@kolivas.org>
To: Nick Piggin <piggin@cyberone.com.au>
Cc: Martin Schlemmer <azarah@gentoo.org>,
	linux kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH]O14int
Date: Mon, 11 Aug 2003 19:43:49 +1000	[thread overview]
Message-ID: <200308111943.49235.kernel@kolivas.org> (raw)
In-Reply-To: <3F375EBD.5030106@cyberone.com.au>

On Mon, 11 Aug 2003 19:15, Nick Piggin wrote:
> Con Kolivas wrote:
> >On Mon, 11 Aug 2003 15:44, Martin Schlemmer wrote:
> >>On Sat, 2003-08-09 at 11:04, Con Kolivas wrote:
> >>>On Sat, 9 Aug 2003 01:49, Con Kolivas wrote:
> >>>>More duck tape interactivity tweaks
> >>>
> >>>s/duck/duct
> >>>
> >>>>Wli pointed out an error in the nanosecond to jiffy conversion which
> >>>>may have been causing too easy to migrate tasks on smp (? performance
> >>>>change).
> >>>
> >>>Looks like I broke SMP build with this. Will fix soon; don't bother
> >>>trying this on SMP yet.
> >>
> >>Not to be nasty or such, but all these patches have taken
> >>a very responsive HT box to one that have issues with multiple
> >>make -j10's running and random jerkyness.
> >
> >A UP HT box you mean? That shouldn't be capable of running multiple make
> > -j10s without some noticable effect. Apart from looking impressive, there
> > is no point in having 30 cpu heavy things running with only 1 and a bit
> > processor and the machine being smooth as silk; the cpu heavy things will
> > just be unfairly starved in the interest of appearance (I can do that
> > easily enough). Please give details if there is a specific issue you
> > think I've broken or else I wont know about it.
>
> Yeah make -j10s won't be without impact, but I think for a lot of
> interactive stuff they don't need a lot of CPU, just to get it
> in a timely manner. And Martin did say it had been responsive.
> Sounds like in this case your changes are causing the interactive
> stuff to get less CPU or higher scheduling latency?

Sigh..,

No, it sounds to me like things are expiring faster than on default. He didn't 
say make -j10, it was multiple -j10s. This is one where you simply cannot let 
the scheduler keep starving the make -j10s indefinitely for X; on a server or 
multiuser box X will simply cause unfair starvation. I'm trying to find a 
workaround for this without rewriting whole sections of the scheduler code, 
but I'm just not sure I should be trying to optimise for a desktop that runs 
loads >16 per cpu. (I'll keep trying though, but if there is no workaround 
that remains fair it wont happen)

Con


  reply	other threads:[~2003-08-11  9:38 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-08 15:49 [PATCH]O14int Con Kolivas
2003-08-08 17:57 ` [PATCH]O14int Timothy Miller
2003-08-09  0:44   ` [PATCH]O14int Con Kolivas
2003-08-08 19:31 ` [PATCH]O14int Felipe Alfaro Solana
2003-08-09  9:04 ` [PATCH]O14int Con Kolivas
2003-08-11  5:44   ` [PATCH]O14int Martin Schlemmer
2003-08-11  6:08     ` [PATCH]O14int Con Kolivas
2003-08-11  8:35       ` [PATCH]O14int Martin Schlemmer
2003-08-11  8:37         ` [PATCH]O14int Zwane Mwaikambo
2003-08-11  9:07           ` [PATCH]O14int Con Kolivas
2003-08-11  9:15       ` [PATCH]O14int Nick Piggin
2003-08-11  9:43         ` Con Kolivas [this message]
2003-08-11  9:44           ` [PATCH]O14int Nick Piggin
2003-08-11 14:04             ` [PATCH]O14int Martin Schlemmer
2003-08-11 14:33               ` [PATCH]O14int Con Kolivas
2003-08-11 15:19                 ` [PATCH]O14int Martin Schlemmer
2003-08-13  6:48                   ` [PATCH]O14int Con Kolivas
2003-08-14  6:19                     ` [PATCH]O14int William Lee Irwin III
2003-08-15 23:40                       ` [PATCH]O14int Paul Dickson
2003-08-17  2:20                         ` [PATCH]O14int William Lee Irwin III
2003-08-11 16:31                 ` [PATCH]O14int Mike Galbraith
2003-08-11 23:54               ` [PATCH]O14int Timothy Miller
2003-08-11 13:58           ` [PATCH]O14int Martin Schlemmer
2003-08-11 17:55     ` [PATCH]O14int William Lee Irwin III
  -- strict thread matches above, loose matches on Subject: below --
2003-08-08 20:08 [PATCH]O14int Voluspa
2003-08-09  0:36 ` [PATCH]O14int Con Kolivas
2003-08-10  8:48   ` [PATCH]O14int Simon Kirby
2003-08-10  9:06     ` [PATCH]O14int Con Kolivas
2003-08-12 17:56       ` [PATCH]O14int Simon Kirby
2003-08-12 21:21         ` [PATCH]O14int Con Kolivas
2003-08-10 10:08     ` [PATCH]O14int William Lee Irwin III
2003-08-12 18:36       ` [PATCH]O14int Simon Kirby
2003-08-10 11:17     ` [PATCH]O14int Mike Galbraith

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=200308111943.49235.kernel@kolivas.org \
    --to=kernel@kolivas.org \
    --cc=azarah@gentoo.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox