Received-SPF: pass (google.com: domain of linux-kernel+bounces-130607-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Message-ID: <422feb1a-4b4e-45b6-838a-78e394dec9cc@metaparadigm.com>
Date: Thu, 4 Apr 2024 10:02:10 +1300
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: user-space concurrent pipe buffer scheduler interactions
From: Michael Clark <michael@metaparadigm.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jens Axboe <axboe@kernel.dk>, Ingo Molnar <mingo@redhat.com>,
        Peter Zijlstra <peterz@infradead.org>, linux-kernel@vger.kernel.org
References: <969ccc0f-d909-4b45-908e-e98279777733@metaparadigm.com>
 <CAHk-=wj3khqjXnHmShPj+tZvC=SyUitTZ7BkDO-rqu_aCVPrXA@mail.gmail.com>
 <1a116a43-fd2e-4f03-8a17-75816fc62717@metaparadigm.com>
Content-Language: en-US
Organization: Metaparadigm
In-Reply-To: <1a116a43-fd2e-4f03-8a17-75816fc62717@metaparadigm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 4/4/24 09:39, Michael Clark wrote:
> So maybe it is possible to look at how many LOCK instructions were 
> retired in the last scheduler quantum ideally with retired-success, 
> retired-failed for interlocked-compare-and-swap. Maybe it is just a 
> performance counter and doesn't require perf tracing switched on?

just occurred to me that you could stash the address and width of the 
last failed interlocked-compare-and-swap to deduce wait-on-address or 
even ask the processor in some circumstances to generate a precise 
interrupt so that you could reschedule it. an idle thought. like if it 
is going to fail we might as well jump straight to the scheduler.