On Thu Mar 5, 2026 at 4:50 PM JST, John Hubbard wrote:
> On 3/4/26 11:37 PM, Eliot Courtney wrote:
>> On Wed Mar 4, 2026 at 8:39 PM JST, Danilo Krummrich wrote:
>>> On Wed Mar 4, 2026 at 2:42 AM CET, Eliot Courtney wrote:
>>>> + fn allocate_command(&mut self, size: usize, timeout: Delta) ->
>>>> Result<GspCommand<'_>> {
>>>> + read_poll_timeout(
>>>> + || Ok(self.driver_write_area_size()),
>>>> + |available_bytes| *available_bytes >=
>>>> size_of::<GspMsgElement>() + size,
>>>> + Delta::ZERO,
>>>
>>> Isn't this either creating unneccessary thrashing of the memory controller
>>> or
>>> unnecessary contention at the cache-coherency level?
>>>
>>> I think we should probably add at least a small delay of something around
>>> 1us.
>>
>> This is what nouveau does (specifically `usleep_range(1, 2)`). OTOH,
>> openrm just does a busy wait, which is what I replicated here for now.
>
> Open RM has some ancient bad habits!
>
>> GSP command queue not having space IIUC is meant to be very exceptional.
>> I am not sure which is best, maybe Alex has an opinion, but also happy
>> to change it because that reasoning makes sense to me and I don't know
>> enough about the distribution of how often it would actually need
>> to wait to know if 0 delay is justified.
>
> Almost never! There is a big big difference in how the OS behaves,
> between 0 delay and non-zero delay. Sleeping, if you can afford to
> (and we can, here, IIUC) is far better than a hard spin loop: the
> scheduler can do something reasonable, for one thing.
In this case the rust `read_poll_timeout` has a preemption point, so
maybe the scheduler would be fine?
But, if we can afford to sleep here it does seem better to me.
