public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Timothy Miller <miller@techsource.com>
To: linux-kernel@vger.kernel.org
Subject: Re: Interactivity improvements
Date: Thu, 07 Aug 2003 19:05:30 -0400	[thread overview]
Message-ID: <3F32DB3A.7020604@techsource.com> (raw)
In-Reply-To: E19ksHM-0003Xl-00@calista.inka.de

One comment on two processes bouncing a semaphor...

If certain kinds of sleep, such as sleeping on a semaphor, do not add
any interactivity points, but the act of sleeping on a semaphor DOES
cause SHARING of interactivity points, then those two processes would
not be able to achieve interactive status based on their sleep patterns.

The next thing to do is to somehow notice that the process never sleeps
on I/O or any other sleeping that WOULD indicate interactivity.

The situation is that both processes really ARE CPU hogs, but we don't
detect that based on using up the timeslice.  The solution is to track
what kinds of sleep a process does (counters of the various sorts),
which I'm sure already happens, but the difference is that you do not
penalize for using up the time slice.  You penalize for NOT doing
interactive-indicating I/O.

This is really quite simple.  All you're doing is you stop considering
time-slice expiration in your heuristics, at least directly.  You have a
whole list of different sleep-reasons (Schlafgruende?), it's just that
timeslice expiration isn't one of them, so whenever your sleep-reasons
isn't in the list, you infer that it's timeslice expiration.

That means you have to catch all other reasons and make sure you've
accounted for them, but you get the idea.

Simpler still would be to treat sleeping on a semaphor (or a pipe or
some other IPC) as a timeslice expiration.  That would be equivalent.
Now, if the other process is interactive, then you have a fight on your
hands.

Does the interactive process accumulate and share interactivity points
fast enough to keep the other one moving well?  If one process is
interactive, then, REALLY, you would want the sleeping of the second
process to be a don't-care.  But how can you tell?

If one process is a CPU hog (or perceived as such), and it is blocking
against another process, thus sharing interactivity points, does that
mean the CPU hog shares negative points with the other process?


Please pardon my stream-of-consciousness style in this post.





  reply	other threads:[~2003-08-07 22:52 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-07 14:26 Interactivity improvements Patrick McLean
2003-08-07 15:24 ` Richard Curnow
2003-08-07 15:42   ` Patrick McLean
2003-08-07 18:33     ` Mike Fedyk
2003-08-07 20:48   ` William Lee Irwin III
2003-08-07 21:26     ` Bernd Eckenfels
2003-08-07 23:05       ` Timothy Miller [this message]
2003-08-07 15:31 ` Felipe Alfaro Solana
2003-08-07 17:41 ` Robert Love
  -- strict thread matches above, loose matches on Subject: below --
2003-08-04 16:07 [PATCH] O13int for interactivity Con Kolivas
2003-08-05  2:20 ` Con Kolivas
2003-08-05  2:21   ` Nick Piggin
2003-08-05  3:06     ` Con Kolivas
2003-08-05  3:17       ` Nick Piggin
2003-08-06 18:48         ` Interactivity improvements Timothy Miller
2003-08-06 19:01           ` Mike Fedyk
2003-08-06 20:09           ` Helge Hafting
2003-08-06 21:15           ` Con Kolivas

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=3F32DB3A.7020604@techsource.com \
    --to=miller@techsource.com \
    --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