David Edmondson wrote:
> On Tue, Sep 02, 2008 at 03:44:08PM -0700, Chaoyue Xiong wrote:
>
>> On 08/18/08 08:06 AM, David Edmondson wrote:
>>
>>> I'd like reviewers for:
>>>
>>> 6721983 High CPU utilization @dom0 when doing Tx at one guest domain
>>> due to a hot lock in the xnb driver
>>> 6730667 High CPU utilization @domU when doing Rx at one guest domain
>>> due to massive calling of mac_tx_update
>>>
>>> The webrev is at http://dme.org/solaris/webrev/on-bugfix.hg.
>>>
>> In xnf_intr function, the current logic is to reclaim Tx ring
>> whenever xnf gets an interrupt. I suggest we change the
>> logic as such that the code reclaims Tx ring ONLY when xnf
>> needs to send packets. This is to avoid grabbing xnf_txlock
>> as much as possible.
>>
>
> We need to hold xnf_txlock to check xnf_need_sched. Hence, we
> might write:
>
> mutex_enter(&xnfp->xnf_txlock);
> if (xnfp->xnf_need_sched) {
> no = xnf_clean_tx_ring(xnfp);
> if (no > 0) {
> mac_tx_update(xnfp->xnf_mh);
> xnfp->xnf_need_sched = B_FALSE;
> }
> }
> mutex_exit(&xnfp->xnf_txlock);
>
If we don't hold the lock for check, I feel we won't have serious
functional
problem here. What do you think of the following change?
if (xnfp->xnf_need_sched) {
no = xnf_clean_tx_ring(xnfp);
if (no > 0) {
mac_tx_update(xnfp->xnf_mh);
mutex_enter(&xnfp->xnf_txlock);
xnfp->xnf_need_sched = B_FALSE;
mutex_exit(&xnfp->xnf_txlock);
}
}
> This would avoid the call to xnf_clean_tx_ring(), but we would still
> end up taking the lock.
>
> Given that xnf_send_one() cleans the ring before sending, I can't see
> why the approach above would be bad.
>
> It also occurs to me that xnf_send() might call xnf_clean_tx_ring()
> rather than xnf_send_one(), meaning that we could reduce the number of
> attempts to clean the ring from "once per packet" to "once per
> chain".
>
> The fixes that we're reviewing now have an approved RTI (while I was
> away on holiday), so I'd like to get those back into the gate and then
> pursue this as a separate item. Could you file an RFE please?
>
Sure, I will file an RFE on this.
-Joy
_______________________________________________
xen-discuss mailing list
[email protected]
