> Darren J Moffat wrote: > > 1. A new kernel-thread-only scheduling class, SDC > > (System Duty Cycle) is introduced. Since the > > list of scheduling classes is user-visible through > > dispadmin(1M) and priocntl(1), we feel an ARC case > > is appropriate. > > User visible or not, I'd think a scheduling class is an interesting > architectural attribute. "User visible" isn't the only reason for ARC > review. > > > 2. In order to improve the observability of ZFS IO processing, > > we introduce a new system process per-zpool, with a > > u_comm and u_psargs of zpool-<poolname> (i.e. zpool-foo). > > The LWPs in the process are kernel threads associated > > with IO processing. Since these threads have LWPs, they > > get microstate accounting data. Thus, CPU usage associated > > with IO processing can be observed using prstat(1M) and ps(1). > > Is this new class usable only by ZFS, or is it potentially usable by > other kernel tasks as well? It looks to me like it could be used to > make work done by networking squeues and STREAMS service procedures more > observable.
It is potentially usable by other kernel tasks. There is nothing ZFS-specific about the class right now, although it makes some very mild assumptions about the characteristics of ZFS' workload (e.g. that it's processing many fairly small tasks, rather than a few large ones). These assumptions basically just have performance implications, rather than correctness ones, and changing them would be fairly straightforward -- on the order of adding of a new flag to an interface -- but we didn't do so because there were no other current consumers of such generalization. The "zpool-<poolname>" process is created separately from the scheduling class. It allows the CPU time from the ZFS task queues (which are now running under SDC) to be more easily observed. Blake
