lkml.org 
[lkml]   [2004]   [Apr]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: disable-cap-mlock
On Thu, Apr 01, 2004 at 06:49:07PM -0800, Andrew Morton wrote:
> Andrea Arcangeli <andrea@suse.de> wrote:
> >
> > > One thing I was wondering was whether /proc/sys/vm/disable_cap_mlock should
> > > hold a GID rather than a boolean. So you do
> > >
> > > echo groupof oracle > /proc/sys/vm/disable_cap_mlock
> >
> > that's probably optimal OTOH that would complicate the code, I prefer an
> > obviously safe !disable_cap_mlock, if we want to go complicated we can
> > probably wait the userspace solution ;)
>
> That depends on how you structure the code. If you do it the below way,
> it's a one-liner.

after you did this cleanup effort I'll have to merge your version ;)

>
> (Will the compiler propagate `unlikeliness' out of an inline function?)

it should, both need_resched and signal_pending depends on it, but I
don't think unlikely is correct, it's likely infact, optimizing for an
application returning -EPERM doesn't sound worthwhile, so I'll change it
to "likely".

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

\
 
 \ /
  Last update: 2005-03-22 14:02    [W:0.086 / U:0.300 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site