From: Peter Zijlstra <peterz@infradead.org>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
David Miller <davem@davemloft.net>,
ben@decadent.org.uk, mkl@pengutronix.de,
linux-rt-users <linux-rt-users@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
netdev@vger.kernel.org, kernel@pengutronix.de
Subject: Re: [PATCH] net: sched: dev_deactivate_many(): use msleep(1) instead of yield() to wait for outstanding qdisc_run callsb
Date: Fri, 4 Apr 2014 17:19:42 +0200 [thread overview]
Message-ID: <20140404151942.GI10526@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <1396437459.3989.39.camel@edumazet-glaptop2.roam.corp.google.com>
On Wed, Apr 02, 2014 at 04:17:39AM -0700, Eric Dumazet wrote:
> On Wed, 2014-04-02 at 13:07 +0200, Peter Zijlstra wrote:
> > On Mon, Mar 31, 2014 at 11:49:16PM +0200, Thomas Gleixner wrote:
> > > > >> The intent of a yield() call, like this one here, is unambiguously
> > > > >> that the current thread cannot do anything until some other thread
> > > > >> gets onto the cpu and makes forward progress.
> >
> > Yeah; like Thomas said; that's not what yield() does -- or can do.
> >
> > yield() only says 'I don't know what to do, you figure it out', but then
> > fails to provide enough information to actually do something sensible.
> >
> > It cannot put the task to sleep; because it doesn't pair with a wakeup;
> > and therefore the task stays an eligible/runnable task from a scheduler
> > pov.
> >
> > The scheduler is therefore entirely in its right to pick this task
> > again; and pretty much has to under many circumstances.
> >
> > yield() does not, and can not, guarantee forward progress - ever.
> >
> > Use wait_event() and assorted bits to wait for an actual event. That is
> > a sleep paired with a wakeup and thus has progress guarantees.
>
> Why wouldn't it be safe to redefine yield as msleep(1) ?
Because it violates what POSIX says what yield() should do. There is a
semi valid use-case for yield between RR/FIFO tasks of the same
priority. Changing yield to do msleep(1) would break that.
The kernel actually used to rely on that particular semantics; but I
think we took that out because it was fragile as heck.
> net/ipv4/tcp_output.c seems to also use yield().
>
>
> /* Socket is locked, keep trying until memory is available. */
> for (;;) {
> skb = alloc_skb_fclone(MAX_TCP_HEADER,
> sk->sk_allocation);
> if (skb)
> break;
> yield();
> }
Yeah, that's crap code too.
Furthermore, changing the network code to use msleep(1) instead of
yield() doesn't make it less crap than it was, just functional crap
instead of broken crap.
The proper way to fix the dev_deactivate_many() is to use wait_event(),
polling for that state is just daft. Afaict there is no reason the qdisc
code could not do a wakeup whenever that condition changes.
And the above loop in tcp_output() is a plain memory deadlock, you
should not loop on allocations like that. If the allocation fails;
propagate the error.
Given that this function must not fail; one should pre-allocate proper
reserves, not simply loop until it works. The loop might be holding up
the work required to release memory.
next prev parent reply other threads:[~2014-04-04 15:19 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-04 23:49 [PATCH] net: sched: dev_deactivate_many(): use msleep(1) instead of yield() to wait for outstanding qdisc_run calls Marc Kleine-Budde
2014-03-06 21:06 ` David Miller
2014-03-06 21:39 ` Marc Kleine-Budde
2014-03-07 15:47 ` Sebastian Andrzej Siewior
2014-03-07 4:26 ` Mike Galbraith
2014-03-09 19:09 ` Ben Hutchings
2014-03-09 22:53 ` David Miller
2014-03-09 23:17 ` Ben Hutchings
2014-03-09 23:28 ` David Lang
2014-03-10 0:07 ` Stanislav Meduna
2014-03-31 21:49 ` [PATCH] net: sched: dev_deactivate_many(): use msleep(1) instead of yield() to wait for outstanding qdisc_run callsb Thomas Gleixner
2014-04-02 11:07 ` Peter Zijlstra
2014-04-02 11:17 ` Eric Dumazet
2014-04-04 15:19 ` Peter Zijlstra [this message]
2014-04-04 15:26 ` David Miller
2014-04-07 11:19 ` Peter Zijlstra
2014-04-04 15:28 ` David Miller
2014-04-07 11:24 ` Peter Zijlstra
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=20140404151942.GI10526@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=ben@decadent.org.uk \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=kernel@pengutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=mkl@pengutronix.de \
--cc=netdev@vger.kernel.org \
--cc=tglx@linutronix.de \
/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
Powered by JetHome