lkml.org 
[lkml]   [2004]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

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