[EMAIL PROTECTED] wrote on Mon, 05 Jun 2006 10:53 -0500:
> Pete, I think you're on to something! Adding the sched_yield() call to
> the BMI_ib_testcontext() function has sped things up tremendously. In
> addition, pvfs2-server now only shows 10% CPU usage (and not for nearly
> as long as previously) in top when doing the pvfs2-mkdir command.
>
> I've attached the pvfs2-server.log for a pvfs2-mkdir after adding the
> sync_yield call. The fact that a mkdir still takes 10% of the CPU still
> bothers me, so I'm wondering if there is still some small thread
> starvation problem somewhere else. What do you think?
Wow! The section I had been looking at in previous traces now all
have the same timestamp value, meaning that it completed in less
than 10 ms.
I think we can declare success and chalk it up to weird scheduler
behavior. I'll run some tests myself, then probably stick that
sched_yield in the source, as it should be harmless for more recent
kernels in that location.
The fact that mkdir is eating 10% CPU on the server is due to this
continuous polling thing that's in there. Even when yielding the
processor to the dbpf thread once in a while, the bmi thread will
still busywait for 1 sec hoping to get some more action from the
network. When we switch to event-driven rather than polling, this
should go away (or at least be configurable to go away).
Thanks for your perseverance. Let us know if you find other
breakage.
-- Pete
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
