Soren Schmidt wrote:
>
> 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.
Implementing some (optional) benchmarking code for the locks would
make it pretty simple to do this as a follow-on project, once the
initial "several-sorta-big-locks" project is stable. There's always
room for improvement.
> > 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 :)
I have disk space available. ;^) Actually, I have a DLT drive
available now, too.
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters Softweyr LLC
http://www.softweyr.com/~softweyr w...@softweyr.com
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
