[Pvfs2-developers] server threads and kernel timers

Sam Lang slang at mcs.anl.gov
Wed Dec 13 10:29:29 EST 2006


On Dec 13, 2006, at 8:45 AM, Pete Wyckoff wrote:

> slang at mcs.anl.gov wrote on Mon, 11 Dec 2006 14:34 -0600:
>> This is some really nice analysis Pete.  One thing we might consider
>> for reducing context switches would be to re-use the coalescing ideas
>> we've tried to apply for meta data syncs to context switches as
>> well.  If we've got a lot of operations completing in a particular
>> module (trove for example), we can just signal once instead of for
>> each operation.  The sync coalescing code already does this, but you
>> would only see any benefits from that with a bunch of clients.
>
> Maybe that would be effective for a loaded server, but that won't
> help single-op latency much.
>
>> The locking and context switches are inherent to our design of server
>> module separation and queueing framework.  I think it would be hard
>> to replace the context switches without doing some serious redesign.
>
> Agreed.
>
>> We might be able to eliminate the trove thread though.  It doesn't do
>> anything but move items from the trove completion queue to the job
>> completion queue.  Since that thread waits on a condition variable
>> (and gets signalled by trove), and then signals the job completion
>> condition variable, we're essentially doing a double context switch
>> when we only need one.  Instead we could change the trove apis to
>> take a callback and user ptr, and have the callback add the completed
>> job to the completion queue directly.  The bits of flow that use job
>> callbacks with trove would have to be changed too, but I think the
>> flows would benefit from the bmi callback being called directly from
>> trove as well.  Does this seem reasonable?
>
> This is a good idea.  The job- or flow-supplied callback function
> can do whatever locking it needs to do protect its own resources.
> Before the callback is invoked you can make sure the completion is
> out of any trove lists.  If you are interested in doing this part,
> I'll be happy to do some more timing tests.

Yeah I'll try to take a whack at it.

-sam

>
> 		-- Pete
>



More information about the Pvfs2-developers mailing list