public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jakob Oestergaard <jakob@unthought.net>
To: Helge Hafting <helgehaf@aitel.hist.no>
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.5.66-(bk) == horrible response times for non X11 applications
Date: Wed, 9 Apr 2003 11:26:28 +0200	[thread overview]
Message-ID: <20030409092628.GF10141@unthought.net> (raw)
In-Reply-To: <3E93E36A.1050206@aitel.hist.no>

On Wed, Apr 09, 2003 at 11:10:02AM +0200, Helge Hafting wrote:
...
> >Look, I'm not trying to defend the boosting mechanism at all costs - I'm
> >just trying to argue that it's not fundamentally insane.   :)
> 
> I agree that it isn't fundamentally insane, but using the 2.5.66
> mechanism might force you to
> concider some apps "broken" that were fine before.  This forces the
> question of how hard it should be to write a user program.

That is a good and valid point

> 
> 100 screen updates per second doesn't mean it is important if it only
> is twiddling of a baton or some progress bar.  People simply stick such
> things in an outer loop - and that worked out to a update or two
> per second in 1989.  Same code on todays machines results in hundreds
> of updates per second.  Are we going to fix apps as our pcs becomes faster?

nice my_old_compute_intensive_app

We agree that only CPU intensive apps will cause the problem right?

So if we keep the CPU boosting mechanism, but only boost non-niced
processes (makes good sense in my twisted mind at least), we provide the
interactiveness benefits for the general case, and provide an easy way
to run unmaintained (or "semi broken" or whatever we will call them)
applications.

We end up "forcing" the user to nice some (hopefully few) CPU intensive
applications that didn't need nicing before.   I can see that that will
be a problem.

But will it be a bigger problem than not having the interactiveness
boost at all?

Cheers,

-- 
................................................................
:   jakob@unthought.net   : And I see the elder races,         :
:.........................: putrid forms of man                :
:   Jakob Østergaard      : See him rise and claim the earth,  :
:        OZ9ABN           : his downfall is at hand.           :
:.........................:............{Konkhra}...............:

      reply	other threads:[~2003-04-09  9:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-06 22:36 2.5.66-(bk) == horrible response times for non X11 applications Zwane Mwaikambo
2003-04-07  1:24 ` Andrew Morton
2003-04-09  6:42   ` Jakob Oestergaard
2003-04-09  8:01     ` Helge Hafting
2003-04-09  8:52       ` Jakob Oestergaard
2003-04-09  9:10         ` Helge Hafting
2003-04-09  9:26           ` Jakob Oestergaard [this message]

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=20030409092628.GF10141@unthought.net \
    --to=jakob@unthought.net \
    --cc=helgehaf@aitel.hist.no \
    --cc=linux-kernel@vger.kernel.org \
    /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