[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-07 9:25:03
[Download RAW message or body]

I'm still convinced that this global, adjustable mlock limit is needed:

something like this:

        if (locked > (mlockable_pages) )
                goto out;

if the user (root) REALLY want  to mlock all memory (and risk a crash) ,
he can set mlockable_pages = num_physpages  ,
but the default of this value should be something like:
on boxes with <= 16MB RAM:  mlockable_pages = num_physpages * 3/4
on boxes with > 16MB RAM: mlockable_pages = num_physpages - 8MB

That way the 256MB RAM box will be able to mlock up to 248MB as default.
(having a 8MB saefty zone) , but if he really wants to use up all memory
he can even lift this limit, but he has to know what he is doing.

Does the above make sense ?

But since in my case (RT audio apps using large amounts of phys mem),
this mlock() issue is tigthly connected to the lowlatency issue,
and lowlatency performance will not make its way into the mainstream
kernel until 2.6,  we will have to provide a patched kernel anyway.
Therefore we add our own mlock() limits to suit our needs,
but I think other apps can benefit from large mlocked areas too.

Benno.


On Mon, 07 Aug 2000, David Gould wrote:
> On Sun, Aug 06, 2000 at 03:04:01PM +0100, Alan Cox wrote:
> > > No! No sysctl, thank you. Comment clearly says it is bogus, and now it
> > > even hurts. Just delete the check.
> > 
> > Without a check like that people will crash the machine and come and rant on
> > here.
> 
> Hmmm, I guess we need to filter those bad IE commands too ;-)
> 
> Seriously, this check reminds me of the old days when VMS had a hard limit to
> the amount of memory one process could have. We database implementers
> thought this was a bug. Ultimately DEC agreed and removed the limit. Funny
> thing, NT, when it came out years later, had the same silly limit and we
> database implementors still thought it was a bug. And even MS fixed it
> finally.
> 
> This kind of hard coded limit done for "the users protection" is really
> patronizing: "We know better than you where you want to go today".
> 
> If as OS implementors, we cannot anticipate every use of a system, we at
> least should not prohibit some uses arbitrarily.
> 
> Sorry for the rant ...
> 
> -dg
> 
> -- 
> David Gould                                                 dg@suse.com
> SuSE, Inc.,  580 2cd St. #210,  Oakland, CA 94607          510.628.3380
> Shut up, be happy.  The conveniences you demanded are now mandatory.
>            -- Jello Biafra

-
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]