I agree with you there. It's not easy, and I'd claim it's not possible
given that no-one has done it yet, to have a select() call that is speedy
for both 0-10 and 1k file descriptors.
} I take issue with the statement that select scales fine to thousands of
} file descriptors. It doesn't. For fairly trivial workloads it degrades
} to 0 operations per second with more than a few dozen filedescriptors in
} the array, but only one descriptor being active. To sustain decent
} throughput, select needs something like 50% of the filedescriptors in an
} array to be active at every select() call, which makes in unsuitable for
} things like LDAP servers, or HTTP/FTP where the clients are behind slow
} connections or interactive (like in the real world). I've benchmarked
} it -- we should really include something like /dev/epoll in the kernel
} to improve this case.
}
} Still, I think the bitmap approach in this case is useful, as having
} affinity to multiple CPUs can be needed, and it is not a frequently
} occuring operation (unlike select()).
}
} -ben
} --
} "You will be reincarnated as a toad; and you will be much happier."
} -
} 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/
-
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/
This archive was generated by hypermail 2b29 : Sun Jun 23 2002 - 22:00:17 EST