Messages in this thread | | | Date | Thu, 12 Feb 2004 10:49:03 -0800 | From | Tim Hockin <> | Subject | Re: PATCH - raise max_anon limit |
| |
On Thu, Feb 12, 2004 at 12:26:14PM -0500, Jim Houston wrote: > > 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.
the only place I found using idr as-is is posix timers. I haven't looked at it's usage pattern much, but I assume it does use the pointers. I guess we're using up sizeof(void *) for every id we allocate, which is yuck.
Do we need to clone idr.c into bitmap.c and simplify?
> 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
That is the behavior that makes most sense, to me.
> 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.
Is that really worth working around in such a gross way? No offense to the idea, but that's a pretty dumb bug to be hacking a failsafe for :)
-- Tim Hockin Sun Microsystems, Linux Software Engineering thockin@sun.com All opinions are my own, not Sun's - 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/
| |