[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Use of newer locking primitives...
- To: Paul Durrant <xadimgnik@xxxxxxxxx>, "win-pv-devel@xxxxxxxxxxxxxxxxxxxx" <win-pv-devel@xxxxxxxxxxxxxxxxxxxx>
- From: Martin Harvey <martin.harvey@xxxxxxxxxx>
- Date: Tue, 30 Aug 2022 13:04:16 +0000
- Accept-language: en-US
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Q16Aj3Fwg0MSPQD+3YBWdDBCwOMazygfxBiNsokEyKA=; b=O4gnYDN4Lni8UkNpxjGDS8PMMzlG5Y8LZjRakU1YYGiLCdDAcFDdqKNTBIPEcuBi18lKuGbDY/5c8mJwZ7mcftCO387JrowYN1MLNgmEi4nttgdVZtxcVJGgC2ZYD+F+ADvLv1ARk3Wf9jwj7lpAGw32jtIrXe3nGpueY6QLkCvAM9YiV4dpouCBSadBls6f5Uz9A3tHKdbTz0BnHdXeujQcDgQJHRs7rwIRe7ob0ffJOgE5xIJeCREJb+eQ48DAynJVJNSIefX4G2Ap8EHW0xhViFfJSRmC7Ds9BAKRrDqEXkYw8zGNff0h3syUqp2q1/lwaScIgVAeTeYo+0Bzvw==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XXPl3ZIl0nUH4OPmFi1ukh+Ov/OpEzQITi7oiI+I0tQP15FZ0Jjn8qwQ8BiMwHbphzmsIhJfs87qSbcJo1KublWDTvsQBjiCtD3XlyVCWRhSLGIOV5hvz3lkEmXK4Udf/5JyKKecou1L7nMtUqoWwETw/bjk/ODg0dDpPYGjify5NTgeq2c+KQxNUQaotWldbVAdGfHaPci2ZHaJcDhxSdOSn3sz/PQHLb71yX7uz3QHHt7JC2s6DMaxgWkcqOkZJvUDNODkfl1TSfNqTrgh/n0L/F6yQLDl314VUNuMAeq3oI9ZfY8ybUghZvaIgu7YXTzAlMA/9X0mQ+SzMHginw==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Delivery-date: Tue, 30 Aug 2022 13:04:32 +0000
- Ironport-data: A9a23:E7mYcKpY6TGEr4c/fsRztko6gGZeBmIJZBIvgKrLsJaIsI4StFCzt garIBmOa6mPa2akc98kbIS08ksF78OGn9JnTVRo/no2Fysa+JuZCYyVIHmrMnLJJKUvbq7GA +byyDXkBJppJpMJjk71atANlVEliefSAOKU5NfsYkhZXRVjRDoqlSVtkus4hp8AqdWiCkaGt MiaT/f3YTdJ4BYpdDNPg06/gEk35q6q6GhA5gZWic1j5zcyqVFEVPrzGonpR5fIatE8NvK3Q e/F0Ia48gvxl/v6Ior4+lpTWhRiro/6ZWBiuFIPM0SRqkEqShgJ+rQ6LJIhhXJ/0F1lqTzTJ OJl7vRcQS9xVkHFdX90vxNwS0mSNoUekFPLzOTWXWV+ACQqflO1q8iCAn3aMqU5xf96PHB+1 8BFOQA2XAu5hL/t3ImCH7wEasQLdKEHPas5k1Q5lHTzK6ZjRprOBaLX+dVfwTE8wNhUGurTb NYYbjwpawncZxpIOREcD5dWcOWA3yGjNWEH7g/F4/NpswA/zyQouFTpGN/cYMCLQ4NVl1yGq 3Pu9GXlGBAKcteYzFJp91rz17+VwXunA+r+EpWfydll0WGLwlAoNzs5Z2OwnvS5g06HDoc3x 0s8v3BGQbIJ3FyiQtj4UBu5o1aLuxcdX5xbFOhSwB6MzO/M/UOVC3YJShZFacc6r4kmSDoyz FiLktj1Qzt1v9WopWm1876VqXa4P3gTJGpbPCscF1Jbs5/kvZ05iQ/JQpB7Cqmpg9bpGDb2h TeXsCw5gLZVhskOv0mmwW36b/uXjsChZmYICs//BApJMisRiFaZWrGV
- Ironport-hdrordr: A9a23:frYu86y3fpntJcLx8MsvKrPxkuskLtp133Aq2lEZdPULSKGlfp GV9sjziyWetN9IYgBZpTnyAtj6fZq6z+8/3WBxB8brYOCCggeVxe5ZnO/fKlHbehEWs9QtrJ uIEJIOQuEYb2IK6voSiTPQe7lP/DDEytHPuQ609QYPcegeUdAE0+4PMHf4LqQZfml7LKt8MK DZyttMpjKmd3hSRN+8HGM5U+/KoMCOvI76YDYdbiRXpDWmvHeN0vrXAhKY1hARX3dk2rE561 XIlAT/++GKr+y78BnBzGXehq4m1+cJi+EzSvBkuPJlagkEuTzYJ7iJnIfy/gzdldvfqWrCVu O85ivIcf4Dr085NVvF2ycFkzOQrQrGrUWShGNwyEGT3fDRVXY0DdFMipledQac4008vMtk2K YOxG6BsYFLZCmw6xgVyuK4Ii2CrHDE1UYKgKoWlThSQIEeYLheocgW+15UCo4JGGb/5Jo8GO djAcnA7LIOGGnqJkzxry1q2pihT34zFhCJTgwLvdGUySFfmDR8w1EDzMISk38c/NY2SoVC5e 7DLqN0/Ys+OPM+fOZ4HqMMUMG3AmvCTVbFN3+TO03uEOUdN3fEu/fMkccIDSGRCe81JbcJ6e r8uQljxBEPkmrVeLyz9YwO9AzRS2OgWjmowt1C5vFCy83BeIY=
- List-id: Developer list for the Windows PV Drivers subproject <win-pv-devel.lists.xenproject.org>
- Thread-index: Adi8ZD8ojTv0cYRiTIesy/wwgsnlOAAAgQyAAABev9AAANxqAAAAa08gAADiLQAAAAxCMA==
- Thread-topic: Use of newer locking primitives...
-----Original Message-----
From: Paul Durrant <xadimgnik@xxxxxxxxx>
> Surely KeStallExecutionProcessor() is likely to HLT while waiting, so why is
> that going to be better than a yield?
Nope. KeStallExecutionProcessor just pauses, it doesn't HLT, not interrupts
required. It's a spin, so it does a PAUSE.
> Also the yield is only done if the interlocked op fails, which it shouldn't
> do in the normal case.
I'm trying to debug the *worst case* latency which is giving us trouble, not
the normal case.
>
> It would be *really nice* to get vTune / uProf working on guests with all the
> uArchitecture counters working so we could actually find out exactly how many
> cycles get spent where.
>
> We see 99% of TxPollDpc's completing rapidly (microseconds), and then very
> occasionally we get a 4ms PollDpc. This is timing via ETW. If I get time to
> repro it (cpl of weeks), then I might try changing the stall mechanisms, and
> possibly the locking, separately.
>
> Right, that could be because something has just dumped (or is still
dumping) a load of packets on the queue. Whoever has the lock has to drain the
entire queue... that's the lack of fairness I was referring to.
Right OK. I'll have a go at this one on a "suck it and see" approach. I'm
assuming you'd be happy to take a look at approaches supported by some good
profiling data.
MH.
|
