mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Martin Schlemmer <azarah@gentoo.org>
To: Con Kolivas <kernel@kolivas.org>
Cc: Nick Piggin <piggin@cyberone.com.au>,
	linux kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH]O14int
Date: 11 Aug 2003 17:19:40 +0200	[thread overview]
Message-ID: <1060615179.13255.133.camel@workshop.saharacpt.lan> (raw)
In-Reply-To: <200308120033.32391.kernel@kolivas.org>

On Mon, 2003-08-11 at 16:33, Con Kolivas wrote:

> > Also, I am not saying Con should fix it - I am asking if we really
> > want one scheduler that should try to do the right thing for SMP
> > *and* UP.
> 
> No, the same issues that apply to fairness, interactivity, throughput and 
> latency are there regardless of SMP or UP. I've had good reports from SMP in 
> the past; your HT report is the first that it was bad, and I've said that 
> some fairness issues have been addressed which cause those. 
> 
> The current scheduler (with or without some tweak or other) will be in 2.6 and 
> should work as much of the time, in as many settings as possible, well. Since 
> I'm trying to work on it I hope you can report exactly what your issue is and 
> I'll try and address it. Do you really compile jobs make -j10 each time while 
> using your machine? (rhetoric question of course since there is absolutely no 
> advantage to doing that without lots of cpus). If not, how does it perform 
> under your real world conditions?
> 

Normal run of things there is many times 1-3 'make -j6s' running.
Yes, sure, for on of them you prob should use -j4, but hey its
in the head, right =).  No, it is not kernels, it is a variety
of stuff - goes with the distro i guess.  Yes, I have tested
runs of 'make -j12' and 'make -j24' (sorry, should have been more
precise, but -j{6,12,24) was used as testing, with -j6 default)
running dual makes.

With vanilla the mouse pointer, XMMS, switching desktops or
windows is smooth.  If I really hammer the system, it does
'slow down' the general navigation of X a little, but not
so that that mouse pointer is jerky, etc.  With the O??int
patches things starts to 'stutter' under loads that is fairly
under those that vanilla handles fine.  The mouse gets jerky,
switching desktops is notably lagging.

Note that I am not talking about starving XMMS/the make's.
I am just talking general navigation of X.  Yes, even with
vanilla things do start a bit slower, but the mouse goes
where it should, and its not as if the vga struggles to
redraw the screen on desktop switch.  I do not expect the
system to behave for 'interactive' processes and xmms/whatever
as if there is no load - the signs of load is just way more
than with vanilla.


Regards,

-- 
Martin Schlemmer



  reply	other threads:[~2003-08-11 15:25 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         ` [PATCH]O14int Con Kolivas
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                 ` Martin Schlemmer [this message]
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
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=1060615179.13255.133.camel@workshop.saharacpt.lan \
    --to=azarah@gentoo.org \
    --cc=kernel@kolivas.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

Powered by JetHome