[prev in list] [next in list] [prev in thread] [next in thread] 

List:       dri-devel
Subject:    Re: [Dri-devel] radeon_cp_getbuffers return values
From:       Keith Whitwell <keith () tungstengraphics ! com>
Date:       2002-07-30 16:48:49
[Download RAW message or body]

Linus Torvalds wrote:
> 
> On Tue, 30 Jul 2002, Keith Whitwell wrote:
> 
>>However, I'd also like to get rid of the sleep and timeout loop in the kernel
>>and not break backwards compatibility.  If the kernel timeout loop disappears,
>>old versions of the 2d client will break, as they are still testing against
>>EBUSY, and so won't iterate through their own timeout loops -- instant failure.
>>
> 
> This sounds really bad from a performance standpoint - simply because it
> makes the failure path _much_ longer.
> 
> 
>>Thus, longwindedly, I'm going to put the clients back to testing EBUSY, remove
>>the kernel udelay & timeout loop *and* change the kernel to return EBUSY
>>instead of EAGAIN.  That way the existing clients will do a busy loop (though
>>still holding the lock) and new clients can maybe do something better.
>>
> 
> Would it not be better to make them actually sleep (yes, dropping the
> lock, of course) in kernel space? When a buffer becomes free, it can react
> much more quickly to the fact, and it hasn't been busy-looping, so the
> scheduler won't try to penalise the process?

Two issues.
	1) We determine f a buffer is free or not by polling an in-memory scratch 
register.  Fix with interrupts.
	2) Userspace likes to know if the lock has been contended so it can restore 
hardware state (or fix it up somehow).  I guess this can be fixed too, though 
it may be hard to do without breaking compatibility.



> What other kernel interfaces traditionally do is (and this is relevant
> only as a "this is what others have done in similar circumstances"):
> 
>  - default: sleep until the request can complete
> 	NOTE: 99% of all users end up using this

Dropping the lock & sleeping would work perfectly well for us too.

>  - have a nonblocking mode (O_NONBLOCK) , and have a way to explicitly
>    wait for the event to become doable (select())
> 	NOTE: this is used mainly for explicitly threaded environments
> 	and only for "slow" operations (ie the kernel doesn't even expose
> 	this for harddisks, only for things like pipes and sockets)

As the hardware serializes everything, I don't see a need for this for the 3d 
drivers.

> In contrast, an interface that _forces_ busy-looping (and worse, making
> the busy loop a fairly lengthy affair that bounces to the kernel and back)
> is just fundamentally bad - nobody wants to use it, and it performs
> horribly.

Yes, it's crap.

Keith









-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[prev in list] [next in list] [prev in thread] [next in thread]