public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Con Kolivas <kernel@kolivas.org>
To: Wes Janzen <superchkn@sbcglobal.net>
Cc: Mike Galbraith <efault@gmx.de>, Voluspa <lista1@comhem.se>,
	linux kernel mailing list <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@osdl.org>
Subject: Re: [PATCH] O17int
Date: Fri, 22 Aug 2003 10:09:10 +1000	[thread overview]
Message-ID: <1061510950.3f455f26b14fa@kolivas.org> (raw)
In-Reply-To: <3F454532.4030200@sbcglobal.net>

Quoting Wes Janzen <superchkn@sbcglobal.net>:

> I wish I could get mm3 running so I could evaluate those interactivity 
> statements.  I can't imagine it being worse than what I'm experiencing now:

Umm. You didn't mention which kernel/patch? I seem to recall you were using 
Osomething but which?

> That would be compiling the kernel, bunzipping a file, and some cron 
> mandb thing that was running gzip in the background niced.  Plus X and 
> Mozilla, which probably starts the problem.  At the end there, you see 
> things calm down.  That's also the way it starts out, then something 
> sets off the "priority inversion" and the machine becomes completely 
> worthless.  Even the task that are running aren't really accomplishing 
> anything.  So the load goes from around 4/5 into the teens and the 
> context switching makes a corresponding jump.  And then both 
> interactivity AND throughput fall through the floor.
> 
> I can't imagine any interactivity regressions that are worse than this 
> behavior...

If this is Osomething, can you tell me when it started doing this and what 
vanilla does.

> And this happens with just X and Mozilla running.  It happens less often 
> without X running, but still happens.  Even if I'm at a VT, it could 
> take 5-6 seconds for my text to appear after I type.  This happens all 
> the time, about once every few minutes and correlates with a 
> simultaneous increase in context switches and load.

Ditto

> Can you set a cutoff point where if the process uses less that X percent 
> of the max timeslice, it is penalized?  I don't know if it's possible  
> to do a loop of empty spins at some point and time it to find out what 
> the cut-off point should be...otherwise I imagine it would need to be 
> tuned for every processor speed.  Could you use the bogomips to gauge 
> the speed of the machine and use that to determine the min timeslice?  
>  From what I understand above, that would perhaps be more selective than 
> just penalizing every process and have a positive affect on 
> everything...of course I'm open to the possibility that I have it all 
> wrong ;-)

A thought, but unfortunately some arbitrary limit would just be hit by 
everything randomly rather than with any meaningful frequency. The timeslice  
interactive things use up is extremely variable depending on circumstances. 

Con

  reply	other threads:[~2003-08-22  0:09 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-19 15:01 [PATCH] O17int Con Kolivas
2003-08-19 16:39 ` Måns Rullgård
2003-08-20  1:23   ` Con Kolivas
2003-08-20  9:19     ` Måns Rullgård
2003-08-19 18:58 ` Måns Rullgård
2003-08-20  1:19   ` Con Kolivas
2003-08-20  8:53     ` Måns Rullgård
2003-08-20 16:27 ` Wiktor Wodecki
2003-08-20 16:42   ` Nick Piggin
2003-08-20 21:23   ` Con Kolivas
2003-08-21  5:26     ` Con Kolivas
2003-08-21  7:53       ` Mike Galbraith
2003-08-21 11:46         ` Con Kolivas
2003-08-21 15:14           ` Mike Galbraith
2003-08-21 22:18             ` Wes Janzen
2003-08-22  0:09               ` Con Kolivas [this message]
2003-08-22 21:17                 ` Wes Janzen
2003-08-22  0:42               ` Felipe Alfaro Solana
2003-08-22  5:34               ` Mike Galbraith
2003-08-22 20:48                 ` Wes Janzen
2003-08-21 23:59             ` Con Kolivas
2003-08-22  5:11               ` Mike Galbraith
2003-08-21  5:30 ` Apurva Mehta
  -- strict thread matches above, loose matches on Subject: below --
2003-08-20  4:55 Voluspa
2003-08-20  8:00 ` Mike Galbraith
2003-08-20 11:21   ` Con Kolivas
2003-08-20 22:51 Voluspa

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=1061510950.3f455f26b14fa@kolivas.org \
    --to=kernel@kolivas.org \
    --cc=akpm@osdl.org \
    --cc=efault@gmx.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lista1@comhem.se \
    --cc=superchkn@sbcglobal.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox