[EMAIL PROTECTED] wrote on Thu, 14 Feb 2008 17:18 -0600:
> I think the patch looks great. My only concern is that this will make the
> threaded client daemon never get used. My view is that we should probably
> have the threaded version as the default. I think in the general case, the
> threaded version is going to perform better. Its pretty hard to buy a
> system that doesn't have at least two cores today, and even on a
> uni-processor system, the performance of the threaded daemon shouldn't be
> much worse than the non-threaded.
>
> I originally added the threaded client functionality to see if it would
> help performance, but it turned out to be buggy. Maybe with Phil's recent
> thread-safety fixes to the system interfaces, we should revisit making the
> threaded daemon the default.
>
> I'm not sure that the overhead of a single operation will be affected much,
> honestly. We can't disable threads and locking entirely, since we need the
> remount thread running. I think the patch I just committed to fix the
> segfault in HEAD will likely help with individual operation performance
> more than disabling threads would. Just my 2c though.
> Its hard to get a feeling for how much the threaded daemon would help
> without a thorough performance analysis of the two on a number of different
> systems. Something I would like to do at some point, but its pretty low on
> the list.
Your arguments about wanting to favor the threaded client core are
good. I'm just afraid to do that now, at the same time, given there
hasn't even been much testing by us developer types.
My unscientific study of listing 1000 files gives this:
threading disabled (default)
ib28$ time ls -la /pvfs > /dev/null
0.004 user 0.024 sys 0.538 real
ib28$ time ls -la /pvfs > /dev/null
0.008 user 0.016 sys 0.530 real
ib28$ time ls -la /pvfs > /dev/null
0.004 user 0.024 sys 0.529 real
ib28$ time ls -la /pvfs > /dev/null
threading enabled
ib28$ time ls -la /pvfs > /dev/null
0.012 user 0.024 sys 0.548 real
ib28$ time ls -la /pvfs > /dev/null
0.008 user 0.024 sys 0.543 real
ib28$ time ls -la /pvfs > /dev/null
0.000 user 0.036 sys 0.549 real
Pretty minor difference, and doesn't show the benefits of threading
for multiple concurrent operations.
I'll check in my (fixed) patch, which is basically just a cleanup of
the existing threaded client-core build. It does the right thing
with respect to --enable-static --enable-shared etc and only builds
exactly what is required. But it does make the threaded client core
a bit tougher to get at: you have to reconfigure instead of just
change the options to client-core at startup time.
We could all decide to start building with
--enable-threaded-kmod-helper and see if we run into problems. My
basic tests pass with both versions. Then soon/eventually switch
that to be the default.
By the way, if anybody has a suggestion for a better location for
the threading configure options documentation than inside
configure.in, please let me know. At least it is near the code.
-- Pete
_______________________________________________
Pvfs2-developers mailing list
Pvfs2-developers@beowulf-underground.org
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
