mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@suse.de>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Andrew Morton <akpm@zip.com.au>, Paul Faure <paul@engsoc.org>,
	linux-kernel@vger.kernel.org
Subject: Re: Process priority in 2.4.18 (RedHat 7.3)
Date: Fri, 17 May 2002 17:17:56 +0200	[thread overview]
Message-ID: <20020517151755.GH11512@dualathlon.random> (raw)
In-Reply-To: <20020517143537.GG11512@dualathlon.random> <E178jAR-0006gD-00@the-village.bc.nu>

On Fri, May 17, 2002 at 03:57:15PM +0100, Alan Cox wrote:
> Hardly takes a flood of IRQ's. A tiny burst of interrupts will happily
> trigger it 

hmm, tiny != burst. of course sometime ksoftirqd will kick in when it
notices a burst. But it is irrelevant to this thread about SCHED_FIFO +
ksoftirqd.

If there's SCHED_FIFO app in loop, ksoftirqd never runs and we only rely
on the support from irq that we had in 2.4.0 and previous too.

returning to the other issue about the fake burst that stops immediatly,
it should be easy to write a small heuristic to avoid scheduling
ksoftirqd in those cases, two different ways could be to simply count
the number of do_softirq invocations outside ksofitrqd per jiffy and to
skip waking up ksoftirqd if the frequency is high enough, this would fix
the minor schedule overhead during the fake burst, however this may not
be optimal for NAPI if for whatever reason there's an irq flood from
some other device in background, so I would actually prefer to detect
when ksoftirqd stops immediatly, it's a bit more complicated but more
generic, if it always stops immediatly then we make it harder to kick it
in. Note that I also benchmarked the effect softirqd in the early days
and I couldn't notice any performance drawback with using netpipe on
100Mbit tulip both on the small fragments (higher burst) and on the big
fragments, so whatever regression it is it is a minor issue and it
definitely pays off the polishing of all the other important cases so
cleanly (NAPI, rcu-poll, ppa, irq flood even on 10Mbit, even if you
block the hard irq with ratelimit you still can hang in the softirq code
without ksofitrqd otherwise you risk to introduce a 10msec latency to
the softirq processing, you don't know how long the softirq load takes
etc..).  It is true that even with ksoftirqd you may hang if the softirq
load takes exactly the same frequency of the do_softirq calls, but
that's not a pratical case, you cannot stay exactly on the border for a
relevant time, while you can pratically go over the border as long as
you want.

Andrea

  reply	other threads:[~2002-05-17 16:09 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3CE414BF.15A0C74B@zip.com.au>
2002-05-16 20:51 ` Paul Faure
2002-05-16 21:06   ` Andrew Morton
2002-05-16 21:57     ` Andrea Arcangeli
2002-05-17  0:40       ` Paul Faure
2002-05-17  2:21         ` Andrew Morton
2002-05-17 12:49           ` Alan Cox
2002-05-17 12:39             ` Andrea Arcangeli
2002-05-17 13:01               ` Alan Cox
2002-05-17 12:55                 ` Andrea Arcangeli
2002-05-17 14:51                   ` Alan Cox
2002-05-17 14:35                     ` Andrea Arcangeli
2002-05-17 14:57                       ` Alan Cox
2002-05-17 15:17                         ` Andrea Arcangeli [this message]
2002-05-17 17:17                           ` Alan Cox
2002-05-18 16:19                             ` Paul Faure
2002-05-18 16:21                             ` Paul Faure
2002-05-17 16:21             ` Paul Faure
2002-05-16 20:08 Paul Faure
2002-05-16 20:13 ` Nerijus Baliunas

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=20020517151755.GH11512@dualathlon.random \
    --to=andrea@suse.de \
    --cc=akpm@zip.com.au \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paul@engsoc.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

all inboxes | Powered by JetHome®