public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@suse.de>
To: linux-kernel@vger.kernel.org
Cc: Andrey Nekrasov <andy@spylog.ru>
Subject: Re: 2.4.19pre9aa2
Date: Fri, 31 May 2002 20:40:14 +0200	[thread overview]
Message-ID: <20020531184014.GJ1172@dualathlon.random> (raw)
In-Reply-To: <20020531051841.GA1172@dualathlon.random> <20020531131306.GA29960@spylog.ru>

On Fri, May 31, 2002 at 05:13:06PM +0400, Andrey Nekrasov wrote:
> Hello Andrea Arcangeli,
> 
> 
> Stability fine. [..]

Cool thanks :)

> [..] But something happened with interactivity. If to start the
> countable task, enter on the computer on ssh, to make "su" - bothers to wait.
> 
> On 2.4.19pre8aa3 such was not. Because of "O1"?

if it's a userspace-cpu intensive background load, most probably because
of o1. The dyn-sched (before I integraed o1 that obsoleted it) was very
good at detecting cpu hogs and to avoid them to disturb interactive
tasks like ssh-shell, of course o1 also has a sleep_time/sleep_avg
derived from the dyn-sched idea from Davide, but maybe the constants are
tuned in a different manner.

Can you try to renice at +19 the cpu hogs and see if you still get bad
interactivity?

The other possibility is that the bad interactivity is due to bad
sched-latency, so that the scheduler posts a reschedule via irq
(schedule_tick()) but the function schedule() is never invoked because
the kernel spins on a loop etc... Now the fixes to prune_icache might
have increased the sched-latency in some case when you shrink the cache
but in turn now you release the inodes and also we roll the list, so
overall should be even an improvement for sched latency for you. And I
doubt you're exercising such path so frequently that it makes a
difference (even if you're certainly exercising it to test the fix
worked). So I would suggest to run some readprofile and to see if
prune_icache/invalidate_inode_pages goes up a lot in the profiling. Also
please check if the cpu load is all in userspace during the bad
interactivity, if it's all userspace load the bad sched latency is
almost certainly not the case.

Andrea

  reply	other threads:[~2002-05-31 18:40 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-05-31  5:18 2.4.19pre9aa2 Andrea Arcangeli
2002-05-31 13:13 ` 2.4.19pre9aa2 Andrey Nekrasov
2002-05-31 18:40   ` Andrea Arcangeli [this message]
2002-05-31 19:55     ` 2.4.19pre9aa2 Andrew Morton
  -- strict thread matches above, loose matches on Subject: below --
2002-06-03 12:15 2.4.19pre9aa2 rwhron
2002-06-03 23:59 ` 2.4.19pre9aa2 Andrea Arcangeli
2002-06-04 12:44 2.4.19pre9aa2 rwhron
2002-06-04 13:01 ` 2.4.19pre9aa2 Andrea Arcangeli

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=20020531184014.GJ1172@dualathlon.random \
    --to=andrea@suse.de \
    --cc=andy@spylog.ru \
    --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