Nicolas Williams wrote: > On Wed, Jun 10, 2009 at 10:09:32PM -0700, Glenn Barry wrote: > >> 6791302 RPCSEC_GSS svc should be able to handle a misbehaving client >> >> http://cr.opensolaris.org/~gtb/6791302/webrev-O/ >> > > Yay. > > Comments: > > - usr/src/uts/common/rpc/sec_gss/svc_rpcsec_gss.c:235-236 > > 235 +/* gssd is single threaded, so 1 thread for the taskq is probably > good/ok */ > 236 +int rpcsec_gss_init_taskq_nthreads = 1; > > I'd rather that as many taskq threads as CPUs be created. It doesn't > matter than gssd is currently single-threaded -- we should want it to > be multi-threaded, and we should not have to change this code when it > does become multi-threaded. > >
gtb: Yea, wanted to keep this simple and match gssd for now. If gssd ever becomes MT-hot, we can auto-tune this up if needbe. And by then should have some good production experience with how the offloading to a taskq behaves. (I talked to Nico via IM and he agreed to go with what we have now.) > (Actually, the right number of threads is a bit harder to determine > since ideally it might be the larger of 1 or NCPU - 2, plus it should > dynamically changes as the number of CPUs changes through DR. But it > doesn't really have to be that fancy here.) > > Other ways to address this would be to use the non-DDI > taskq_create_instance() and TASKQ_THREADS_CPU_PCT flag and the > percentage given as, say, 50. > > Nico >
