[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-kernel
Subject:    Re: can't mlockall() more than 128MB, is this a kernel limitiation ?
From:       Benno Senoner <sbenno () gardena ! net>
Date:       2000-08-06 10:46:31
[Download RAW message or body]

On Sat, 05 Aug 2000, Pavel Machek wrote:
> 
> > Can we make this configurable via sysctl in 2.4 ?
> > (without this realtime multimedia apps will be unable to take advantage of the
> > full amount of RAM, because swappable mem is useless in certain
> > cases)
> 
> No! No sysctl, thank you. Comment clearly says it is bogus, and now it
> even hurts. Just delete the check.
> 								Pavel

But the question is: will it be deleted in 2.4-final ?
What was the initial purpose of the check ?
To avoid OOM/starvation conditions ?

But even if the bogus check will be deleted, I think it would perhaps be handy
to specify a "saefty margin" of non mlock-able mem, or the kernel will in some
cases not have any phys pages left for swapping in and out mem.
But the same applies to the memory overcommit problem.

What would the optimal tradeoff look like ?
BTW: any idea how other UNICES solve this problem ?

But OTOH, speaking of realtime multimedia apps, being run SCHED_FIFO, they can
"lock up" the machine when entering in an infinite computation loop without
releasing the CPU, thus even with that mlock() saefty margin, the app developer
has still to make sure that the application is not buggy if he wants to avoid
lockups.
Therefore one could argue that the safety zone is useless for "system stability"

comments ?

Benno.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

[prev in list] [next in list] [prev in thread] [next in thread]