From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: David Miller <davem@davemloft.net>,
linux-rt-users@vger.kernel.org, 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 calls
Date: Fri, 7 Mar 2014 16:47:39 +0100 [thread overview]
Message-ID: <20140307154739.GA18441@linutronix.de> (raw)
In-Reply-To: <5318EB2E.8040707@pengutronix.de>
* Marc Kleine-Budde | 2014-03-06 22:39:58 [+0100]:
>> Therefore it should allow lower priority threads to run, not just
>> equal or higher priority ones.
>
>Yes, we need a call that does what you described, however I'm not sure
>if yield() really does that. According to:
>
>http://lxr.free-electrons.com/source/kernel/sched/core.c#L3599
>
>> * Typical broken usage is:
>> *
>> * while (!event)
>> * yield();
>> *
>> * where one assumes that yield() will let 'the other' process run that will
>> * make event true. If the current task is a SCHED_FIFO task that will never
>> * happen. Never use yield() as a progress guarantee!!
>
>My Process runs with SCHED_FIFO and prio > 50, with IRQ at default prio,
>which is 50.
>
>Maybe the RT guys can comment on this. I found another interesting
>function in the RT patch set: cpu_chill().
If you boot mainline without -RT, use threadirqs, start your application
do the same prio thing then you should end up with exactly the same
outcome. Please say so :)
msleep() is safe as long as it is used outside of the softirq. Nice that
you found cpu_chill() but on non-RT it turns to cpu_relax() and you do
not want this here.
wait_event() would be nice in the end to have. For now I take that patch
for -RT.
>Marc
Sebastian
next prev parent reply other threads:[~2014-03-07 15:47 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 [this message]
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
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=20140307154739.GA18441@linutronix.de \
--to=bigeasy@linutronix.de \
--cc=davem@davemloft.net \
--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 \
/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.