Krishna Yenduri wrote: > Bart Smaalders wrote: >> ... >> Keep in mind the differences between lwps and kernel threads, esp. on >> NUMA (MPO) platforms. Note that lgrp_choose isn't called for kernel >> threads.... >> > > That explains it then. Thanks. > >> What are you trying to do? >> > > The kernel test models the behavior of a kernel crypto user like KSSL. > We are not getting the expected crypto throughput with this kernel test > and the root cause turned out to be the poor initial thread placement. > > I get the expected throughput if I bind each thread to a CPU > using thread_affinity_set(). But, we don't want to require the kernel > crypto users to do this binding. The ideal solution > would be that the scheduler does optimal initial thread placement. > >> Trying to use all the cpus in the system at minclsyspri is likely to >> make interactive >> use awkward, to say the least > > Understood. The problem is seen even with 16 threads. I just picked > ncpus (128) as the extreme case. > > Regards, > -Krishna
I'd check some impl. details; kernel threads are supposed to run in lgrp 0 IIRC to prevent annoying re-homing behaviors due to typical short run times at high prio.. most kernel threads have very poor cache or memory locality so running them in random places that don't displace long-running threads w/ good affinity would be a performance win... - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
