________________________________________ Ian Lepore wrote: [stuff snipped] >taskqueue(9) is an existing mechanism to enqueue functions to execute >asynch using a pool of threads, but it doesn't answer the scalability >questions. In fact it may make them harder, inasmuch as I don't think >there's a mechanism to dynamically adjust the number of threads after >first calling taskqueue_start_threads(). I've coded it using taskqueue and it seems to work ok. The patch is here, in case anyone would like to review it: https://www.reviews.freebsd.org/D12632 I don't know what the overheads are (or even how to measure/compare them), but I suspect it is less than a kproc_create()/kproc_exit() for every RPC. I also don't think having a fixed # of threads is a problem. Since NFS I/O is so bursty, recent I/O activity doesn't give a good indication of how many threads will be needed soon. In other words, it can go from no I/O to heavy I/O and back to no I/O rapidly. --> As such, having a fixed reasonable # of threads is probably the best that can be done. - The current patch has the # of threads as a sysctl with a default of 32. Thanks for your comments and feel free to review it, if you'd like, rickReceived on Mon Oct 09 2017 - 18:25:54 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:13 UTC