Davide Libenzi a écrit :
> Core code for the fdmap implementation. Random allocation, exact allocation,
> de-allocation and lookup are all O(1) operations. It also support the "legacy"
> sequential (compact) file descriptor allocation, that is O(N) like the old
> fdtable implementation.
> Like the old "struct fdtable", fdmap is RCU friendly too.
>
Hi Davide
I just took a 10 minutes look before running away this morning, I'll try to
test this to get performance numbers in about 12 hours.
+ */
+int fdmap_newfd_seq(struct fd_map *fmap, unsigned int start,
+ unsigned int limit, unsigned long flags)
+{
+ int fd;
+
+ if (unlikely(start))
+ start = start - fmap->base;
+ if (likely(start < fmap->fdnext))
+ start = fmap->fdnext;
+ fd = find_next_zero_bit(fmap->map, fmap->size, start);
+ if (unlikely(fd >= limit))
+ return -EMFILE;
+ if (unlikely(fd >= fmap->size))
+ return -ENOSPC;
+ fmap->fdnext = fd + 1;
Here you broke POSIX I'm afraid.
You might need some test like
if (start <= fmap->fdnext)
fmap->fdnext = fd + 1;
Also I'm not sure the first unlikely() and likely() are worth it.
They probably match the user code you wrote yourself :)
Best thing is probably let the compiler generate a 50/50 code and let CPU uses
its predictors.
+
+ return fdmap_alloc_tail(fmap, fd, flags);
+}
/*
* untested prog
* should not fail if/when (ulimit -n 1024)
*/
#include <fcntl.h>
int main()
{
int highfd = fcntl(0, F_DUPFD, 1023);
int fd = open("/dev/null", O_RDONLY);
if (fd == -1) {
perror("open /dev/null");
return 1;
}
return 0;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
