Date: Tue, 26 Aug 2003 01:58:51 -0400 (EDT)
From: Ingo Molnar <mingo@redhat.com>
To: Andrew Morton <akpm@osdl.org>
cc: rusty@rustcorp.com.au, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] Futex non-page-pinning fix
In-Reply-To: <20030825225011.2ad47c85.akpm@osdl.org>
Message-ID: <Pine.LNX.4.44.0308260155490.1912-100000@devserv.devel.redhat.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1139
Lines: 26


On Mon, 25 Aug 2003, Andrew Morton wrote:

> > but if all futexes pin down one page (worst-case), then to make it really
> >  safe we'll have to use a fairly low default RLIM_NRFUTEX value - which
> >  will decrease the generic utility of futexes.
> 
> We could make it RLIM_NRFUTEX_PAGES: the number of pages which the user
> can pin via futexes, perhaps.

the problem is that this is not really a deterministic limit. The nr of
thread or open files limit is deterministic: it will either fail or
succeed at clone() or open() time - and can be freely used afterwards. The
kernel doesnt in fact know about the first use of a futex: no-contention
futexes have zero kernel footprint. This is the big plus of them. So i'd
really favor some sort of hashing method and no limits, that way the Linux
VM is extended and every VM address is waitable and wakable on - a pretty
powerful concept.

	Ingo

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