Greg Banks wrote:
Peter Staubach wrote:
Greg Banks wrote:
[...]
Testing was on a 4 CPU 4 NIC Altix using 4 IRIX clients, each with 16
synthetic client threads simulating an rsync (i.e. recursive directory
listing) workload[...]
Profiling showed schedule() taking 6.7% of every CPU, and __wake_up()
taking 5.2%. This patch drops those contributions to 3.0% and 2.2%.
Load average was over 120 before the patch, and 20.9 after.
[...]
Have you measured the impact of these changes for something
like SpecSFS?
Not individually. This patch was part of some work I did in late
2005/early 2006 which was aimed at improving NFS server performance in
general. I do know that the server's SpecSFS numbers jumped by a factor
of somewhere over 2x, from embarrassingly bad to publishable, when
SpecSFS was re-run after that work. However at the time I did not have
the ability to run SpecSFS myself, it was run by a separate group of
people who had dedicated hardware and experience. So I can't tell what
contribution this particular patch made to the overall SpecSFS
improvements. Sorry.
That does sound promising though. :-)
It would be interesting to get some better information regarding
some of the measurable performance ramifications such as SFS
though. The Linux NFS server has not had much attention paid to
it and I suspect that it could use some work in the performance
area.
Thanx...
ps
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
