It seems Arun Sharma wrote: > An alternative way, which requires a good understanding of both the > theory and implementation of the kernel is - > > (a) Implement per subsystem locking
This was exactly what I experimented with some 7-8 month ago, it showed significant improvements in performance, yet it was relatively easy to do. > (b) Figure out in a "typical" workload, how much time is being spent > in which subsystem and try increasing parallelism (i.e. finer > grained locking) in subsystems where more time is being spent. Well, my simple tests showed no need for this, again its a fine balance between spending the time waiting, and spending the time processing locks. > The result of this approach should be more logical, cleaner and > possibly better performing than the previous one. It sure is easier to understand and to maintain. Maybe I should try it again, and this time keep off-site backups :) -Søren To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
