mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: kuznet@ms2.inr.ac.ru
To: andrea@suse.de (Andrea Arcangeli)
Cc: davem@redhat.com, paulus@samba.org, torvalds@transmeta.com,
	alan@lxorguk.ukuu.org.uk, mingo@elte.hu,
	linux-kernel@vger.kernel.org
Subject: Re: softirq in pre3 and all linux ports
Date: Wed, 20 Jun 2001 22:06:13 +0400 (MSK DST)	[thread overview]
Message-ID: <200106201806.WAA19422@ms2.inr.ac.ru> (raw)
In-Reply-To: <20010620060753.B849@athlon.random> from "Andrea Arcangeli" at Jun 20, 1 06:07:53 am

Hello!

> > Andrea Arcangeli writes:
> >  > I don't have gigabit ethernet so I cannot flood my boxes to death.
> >  > But I think it's real, and a softirq marking itself runnable again is
> >  > another case to handle without live lockups or starvation.

Andrea, you do not need gigabit interfaces to check this. 100Mbit ones
are enough and even better, because they do not mitigate as rule
and consume more resources. 8) Actually, you may laugh, but one 10Mbit(!)
interface is enough in some curcumstances, namely when stack does more work
than usually: sniffing, connection tracking in presence of fragments,
syn flooding etc.

Actually, now I do not understand why TUX still works with Ingo's patch.
As soon as bulk work is made in thread context, it should die pretty
fastly doing no progress. :-)


> > I think (still) that you're just moving the problem around and
> > not actually changing anything.

Well, ksoftirqd is not sort of placebo yet. :-)

OK. Let's forget about infinite thread latency and live lock problems
introduced by Ingo's patch. Eventually, BSD does exactly the same
thing for ages and nobody but security paranoics cried about this
too much. We are just fully bsd compliant now. 8)


Let's look at different angle: f.e. with Ingo's patch, as soon as
one cpu processes some global BH, all the rest of cpus will spin
waiting for global bh release. Is this good? I am afraid this is not
quite good.

Alexey


  reply	other threads:[~2001-06-20 18:07 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-06-19 19:03 Andrea Arcangeli
2001-06-20  3:33 ` Paul Mackerras
2001-06-20  3:54   ` Andrea Arcangeli
2001-06-20  4:00   ` David S. Miller
2001-06-20  4:07     ` Andrea Arcangeli
2001-06-20 18:06       ` kuznet [this message]
2001-06-20 22:10       ` David S. Miller
2001-06-20 23:16         ` Andrea Arcangeli
2001-06-21 16:58         ` kuznet
2001-06-20 12:18   ` Paul Mackerras
2001-06-20 12:52     ` Andrea Arcangeli
2001-06-20 18:16   ` kuznet

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=200106201806.WAA19422@ms2.inr.ac.ru \
    --to=kuznet@ms2.inr.ac.ru \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=andrea@suse.de \
    --cc=davem@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=paulus@samba.org \
    --cc=torvalds@transmeta.com \
    /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®