From owner-freebsd-current@freebsd.org Tue Oct 10 02:47:41 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B6FE4E44F68 for ; Tue, 10 Oct 2017 02:47:41 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 91DEE66608; Tue, 10 Oct 2017 02:47:40 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (106-69-250-194.dyn.iinet.net.au [106.69.250.194]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id v9A2lZ0I070339 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 9 Oct 2017 19:47:38 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: RFC how to use kernel procs/threads efficiently To: Rick Macklem , Ian Lepore , "freebsd-current@freebsd.org" References: <1507317060.86205.268.camel@freebsd.org> From: Julian Elischer Message-ID: Date: Tue, 10 Oct 2017 10:47:30 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 02:47:41 -0000 On 10/10/17 4:25 am, Rick Macklem wrote: > ________________________________________ > 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. why not set it to ncpu or something? > > 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-unsubscribe@freebsd.org" >