> Generally real-time applications should not be doing mlock calls during
> their real-time execution for that reason. The required memory regions
> should be locked during startup so that this kind of execution delay can
> be avoided at runtime.
Total agreement on this.
.
Regards,
Bud Da
t...@infradead.org;
kosaki.motoh...@jp.fujitsu.com; linux-kernel@vger.kernel.org
> Subject: RE: Bug 71331 - mlock yields processor to lower priority process
>
> On Fri, 2014-03-21 at 14:01 +, jimmie.da...@l-3com.com wrote:
>
>> If you call mlock () from a SCHED_FIFO task, you expect i
On Thu, 2014-03-27 at 04:20 +, jimmie.da...@l-3com.com wrote:
> The example code submitted into bugzilla (chase back on the thread a
> bit, there is a reference) shows the problem.
>
> Two threads, TaskA (high priority) and TaskB (low priority). Assigned
> to the same processor, explicitly
@vger.kernel.org
Subject: Re: Bug 71331 - mlock yields processor to lower priority process
On 03/21/2014 07:50 AM, jimmie.da...@l-3com.com wrote:
>
>
> From: Mike Galbraith [umgwanakikb...@gmail.com]
> Sent: Friday, March 21, 2014 9:41 AM
> To: D
t...@infradead.org;
> kosaki.motoh...@jp.fujitsu.com; linux-kernel@vger.kernel.org
> Subject: RE: Bug 71331 - mlock yields processor to lower priority process
>
> On Fri, 2014-03-21 at 14:01 +, jimmie.da...@l-3com.com wrote:
>
>> If you call mlock () from a SCHED_FIFO task, you
> Mike,
>
> There are several problem domains where you protect critical sections by
> assigning multiple threads to a single CPU and use priorities
> and SCHED_FIFO to ensure data integrity.
>
> In this kind of design you don't make many syscalls. The ones you do make,
> have to be clearly un
: Bug 71331 - mlock yields processor to lower priority process
On Fri, 2014-03-21 at 14:01 +, jimmie.da...@l-3com.com wrote:
> If you call mlock () from a SCHED_FIFO task, you expect it to return
> when done. You don't expect it to block, and your task to be
> pre-empted.
Sa
On Fri, 2014-03-21 at 14:01 +, jimmie.da...@l-3com.com wrote:
> If you call mlock () from a SCHED_FIFO task, you expect it to return
> when done. You don't expect it to block, and your task to be
> pre-empted.
Say some of your pages are sitting in an nfs swapfile orbiting Neptune,
how do the
yields processor to lower priority process
On Fri, 2014-03-21 at 12:18 +, jimmie.da...@l-3com.com wrote:
> As the submitter of the bug, let me give you my perspective.
> SCHED_FIFO means run my task until it blocks or a higher priority task
> pre-empts it. Period.
It blocked.
: Bug 71331 - mlock yields processor to lower priority process
On Fri, 2014-03-21 at 12:18 +, jimmie.da...@l-3com.com wrote:
>
> >How is that different from any other time a task has to yield the CPU
> >for a bit? While your high priority task is blocked for whatever
> >rea
On Fri, 2014-03-21 at 12:18 +, jimmie.da...@l-3com.com wrote:
>
> >How is that different from any other time a task has to yield the CPU
> >for a bit? While your high priority task is blocked for whatever
> >reason, a lower priority task gets to use the CPU.
>
>
> As the submitter of the
On Fri, 2014-03-21 at 12:18 +, jimmie.da...@l-3com.com wrote:
> As the submitter of the bug, let me give you my perspective.
> SCHED_FIFO means run my task until it blocks or a higher priority task
> pre-empts it. Period.
It blocked.
>
> mlock() doesn't block. check the man page.
>
I don't
>How is that different from any other time a task has to yield the CPU
>for a bit? While your high priority task is blocked for whatever
>reason, a lower priority task gets to use the CPU.
As the submitter of the bug, let me give you my perspective. SCHED_FIFO means
run my task until it bl
On Fri, 2014-03-21 at 23:02 +0300, Artem Fetishev wrote:
> 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 y
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_d
15 matches
Mail list logo
