________________________________________
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, rick
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
