mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Artem Fetishev <artem_fetishev@epam.com>
To: <peterz@infradead.org>, <jmdavis@link.com>,
	<kosaki.motohiro@jp.fujitsu.com>
Cc: <linux-kernel@vger.kernel.org>
Subject: Bug 71331 - mlock yields processor to lower priority process
Date: Fri, 21 Mar 2014 23:02:49 +0300	[thread overview]
Message-ID: <20140321200248.GB6264@owamsq.epam.com> (raw)

Hi all,

I am looking at a use-case when a real-time task (B) of higher priority is sometimes preempted by another real-time task (A) of lower priority. Well, B is not really preempted. It calls mlockall() which forces task B to yield the CPU. Under certain conditions, mlockall() calls lru_add_drain_all() which schedules a deferred work and wants the calling task to wait until that work is complete by putting the task into TASK_UNINTERRUPTIBLE state and calling schedule_timeout().

Tasks utilize SCHED_FIFO policy.

See details here: https://bugzilla.kernel.org/show_bug.cgi?id=71331

Besides mlockall, there are other kernel paths which make use of lru_add_drain_all() and schedule_timeout(), so I guess there are bunch of other syscalls which may lead to the above use-case.

So the question is: is above use-case an expected behavior of real-time tasks or is it a bug in mlockall (i.e. it should not interrupt a real-time process)?

Thanks,
-Artem

             reply	other threads:[~2014-03-21  8:04 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-21 20:02 Artem Fetishev [this message]
2014-03-21  9:23 ` Mike Galbraith
2014-03-21 12:18   ` jimmie.davis
2014-03-21 13:14     ` Mike Galbraith
2014-03-21 14:34       ` jimmie.davis
2014-03-21 14:54         ` Motohiro Kosaki
2014-03-21 13:35     ` Oliver Neukum
2014-03-21 14:01       ` jimmie.davis
2014-03-21 14:41         ` Mike Galbraith
2014-03-21 14:50           ` jimmie.davis
2014-03-27  0:39             ` Andy Lutomirski
2014-03-27  4:20               ` jimmie.davis
2014-03-27  5:35                 ` Mike Galbraith
2014-03-27  6:02             ` Robert Hancock
2014-03-27 11:37               ` jimmie.davis

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=20140321200248.GB6264@owamsq.epam.com \
    --to=artem_fetishev@epam.com \
    --cc=jmdavis@link.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.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®