Date: Mon, 9 Oct 2017 20:25:51 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: Ian Lepore <ian@freebsd.org>, "freebsd-current@freebsd.org" <freebsd-current@freebsd.org> Subject: Re: RFC how to use kernel procs/threads efficiently Message-ID: <YQXPR0101MB0997FAE97A7E42BCF570AA7EDD740@YQXPR0101MB0997.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <1507317060.86205.268.camel@freebsd.org> References: <YQXPR0101MB099752292CCAC9E8A72C1E96DD710@YQXPR0101MB0997.CANPRD01.PROD.OUTLOOK.COM>, <1507317060.86205.268.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
________________________________________ 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 ever= y 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 man= y 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 o= f 32. Thanks for your comments and feel free to review it, if you'd like, rick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YQXPR0101MB0997FAE97A7E42BCF570AA7EDD740>