lkml.org 
[lkml]   [2014]   [Mar]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Bug 71331 - mlock yields processor to lower priority process
On 21/03/14 08:50 AM, jimmie.davis@l-3com.com wrote:>
> ________________________________________
> From: Mike Galbraith [umgwanakikbuti@gmail.com]
> Sent: Friday, March 21, 2014 9:41 AM
> To: Davis, Bud @ SSG - Link
> Cc: oneukum@suse.de; artem_fetishev@epam.com; peterz@infradead.org;
kosaki.motohiro@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 +0000, jimmie.davis@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 they get home, and what should we do meanwhile?
>
> -Mike
>
> Two options.
>
> #1. Return with a status value of EAGAIN.
>
> or
>
> #2. Don't return until you can do it.
>
> If SCHED_FIFO is used, and mlock() is called, the intention of the
user is very clear. Run this task until
> it is completed or it blocks (and until a bit ago, mlock() did not
block).

Returning EAGAIN is not something that the API definition from POSIX
allows for, that is only for indicating a failure. If the memory that is
being locked is not currently residing in RAM, then the memory will need
to be swapped in before the call returns, which clearly cannot be done
without blocking. Thus mlock can potentially block, which has not
changed. Whether or not any kernel behavior has changed to cause this to
happen in some cases where it didn't previously, the fact remains that
this is allowed behavior.

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.

>
> SCHED_FIFO users don't care about fairness. They want the system to
do what it is told.
>
> regards,
> Bud Davis
>
>
>
>
>
>
>
>
>



\
 
 \ /
  Last update: 2014-03-27 07:21    [W:0.067 / U:1.916 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site