Re: PATCH - raise max_anon limit
From: Jim Houston
Date: Thu Feb 12 2004 - 12:29:58 EST
On Wed, 2004-02-11 at 20:20, Andrew Morton wrote:
> Tim Hockin <thockin@xxxxxxx> wrote:
> > No, it doesn't store the counter with the id. They expect you to do that.
> > My best understanding is that thi sis to prevent re-use of the same key.
> > I'm not sure I grok why it is useful. If you release a key, it should be
> > safe to reuse. Period. I assume there was some use case that brought about
> > this "feature" but if so, I don't know what it is. The big comment about it
> > is just confusing me.
>
> Maybe Jim can tell us why it's there. Certainly, the idr interface would
> be more useful if it just returned id's which start from zero.
Hi Andrew, Everyone,
If this new use of idr.c as a sparse bitmap catches on, it might deserve
a new flavor which would not waste the space for the pointer array
at the lowest layer.
When I wrote the original code, I was thinking of allocating process
id values where there is a tradition of allocating sequential values.
George Anzinger rewrote most of my code. The r in idr.c is for
immediate reuse. His version picks the lowest available bit in the
sparse bitmap. The RESERVED_BITS comments seem to be stale.
The rational for avoiding immediate reuse of id values is to catch
application errors. Consider:
fd1 = open_like_call(...);
read(fd1,...);
close(fd1);
fd2 = open_like_call(...);
write(fd1...);
If fd2 has a different value than the recently closed fd1, the
error is detected immediately.
Jim Houston - Concurrent Computer Corp.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/