All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bill Davidsen <davidsen@tmr.com>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Con Kolivas <kernel@kolivas.org>,
	linux <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@osdl.org>, Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH] remove interactive credit
Date: Wed, 03 Nov 2004 17:24:17 -0500	[thread overview]
Message-ID: <41895A91.8090502@tmr.com> (raw)
In-Reply-To: <41877DF5.8070008@yahoo.com.au>

Nick Piggin wrote:
> Con Kolivas wrote:
> 
>> remove interactive credit
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> Special casing tasks by interactive credit was helpful for preventing 
>> fully
>> cpu bound tasks from easily rising to interactive status.
>> However it did not select out tasks that had periods of being fully 
>> cpu bound
>> and then sleeping while waiting on pipes, signals etc. This led to a more
>> disproportionate share of cpu time.
>>
>> Backing this out will no longer special case only fully cpu bound 
>> tasks, and
>> prevents the variable behaviour that occurs at startup before tasks 
>> declare
>> themseleves interactive or not, and speeds up application startup 
>> slightly
>> under certain circumstances. It does cost in interactivity slightly as 
>> load
>> rises but it is worth it for the fairness gains.
>>
>> Signed-off-by: Con Kolivas <kernel@kolivas.org>
>>
> 
> I'm scared :(
> 
> I'm in favour of any attempts to simplify things... but will it be two
> months or three before this spontaneously explodes for half our userbase?
> 
> Andrew's boss so he gets to decide >:)

If I read the intent right, this is an example of worst case avoidance, 
where a little average interactivity is traded for preventing the case 
where a single misguided process gets most/all of the CPU and 
performance falls off the edge of the table. As a user I see that as the 
same line of thought which gave us low-latency patches, to trade a 
miniscule bit of one thing to avoid something really undesirable.

I suspect there will be people who don't want to make this trade, 
although it sounds like a good one to me.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

  reply	other threads:[~2004-11-03 22:31 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-02  4:06 [PATCH] remove interactive credit Con Kolivas
2004-11-02 12:30 ` Nick Piggin
2004-11-03 22:24   ` Bill Davidsen [this message]
2004-11-02 12:37 ` Ingo Molnar
2004-11-02 12:40   ` Con Kolivas
2004-11-02 12:46     ` Ingo Molnar
2004-11-02 12:49       ` Con Kolivas
2004-11-02 12:59         ` Ingo Molnar

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=41895A91.8090502@tmr.com \
    --to=davidsen@tmr.com \
    --cc=akpm@osdl.org \
    --cc=kernel@kolivas.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=nickpiggin@yahoo.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.