Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1211257 > unrolled thread

Re: [PATCHv2] Input: xpad - Fix double URB submission races

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCHv2] Input: xpad - Fix double URB submission races Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2015-08-21 19:00 +0200
    Re: [PATCHv2] Input: xpad - Fix double URB submission races Laura Abbott <labbott@redhat.com> - 2015-08-25 06:30 +0200
      Re: [PATCHv2] Input: xpad - Fix double URB submission races Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2015-08-26 19:20 +0200

#1211257 — Re: [PATCHv2] Input: xpad - Fix double URB submission races

Hi Laura,

On Mon, Aug 10, 2015 at 05:26:12PM -0700, Laura Abbott wrote:
> v2: Created a proper queue for events instead of just dropping them

How long does it take for the queue to exhaust your memory if you keep
bombarding the driver with requests?

I do not think you need a queue. I believe the nature of LEDs and rumble
force feedback effect is such that you can discard all requests but the
latest that arrived between the moment you submitted a request to the
device and the moment you are ready submit a new one.

Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1212689

On 08/21/2015 09:50 AM, Dmitry Torokhov wrote:
> Hi Laura,
>
> On Mon, Aug 10, 2015 at 05:26:12PM -0700, Laura Abbott wrote:
>> v2: Created a proper queue for events instead of just dropping them
>
> How long does it take for the queue to exhaust your memory if you keep
> bombarding the driver with requests?
>

My script which changes the LEDs as fast as possible ran for 7+ hours on
my machine with 16GB of RAM without exhausting all of it. This is also a
very extreme case as almost any kind of delay between sending
commands will drain the queue.
  
> I do not think you need a queue. I believe the nature of LEDs and rumble
> force feedback effect is such that you can discard all requests but the
> latest that arrived between the moment you submitted a request to the
> device and the moment you are ready submit a new one.

So your suggestion is to only keep a single item in the queue?

>
> Thanks.
>

Thanks,
Laura
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1214054

On Mon, Aug 24, 2015 at 9:22 PM, Laura Abbott <labbott@redhat.com> wrote:
> On 08/21/2015 09:50 AM, Dmitry Torokhov wrote:
>>
>> Hi Laura,
>>
>> On Mon, Aug 10, 2015 at 05:26:12PM -0700, Laura Abbott wrote:
>>>
>>> v2: Created a proper queue for events instead of just dropping them
>>
>>
>> How long does it take for the queue to exhaust your memory if you keep
>> bombarding the driver with requests?
>>
>
> My script which changes the LEDs as fast as possible ran for 7+ hours on
> my machine with 16GB of RAM without exhausting all of it. This is also a
> very extreme case as almost any kind of delay between sending
> commands will drain the queue.

Hmm, that means the device is able to process requests pretty fast;
I'm impressed.

>
>>
>> I do not think you need a queue. I believe the nature of LEDs and rumble
>> force feedback effect is such that you can discard all requests but the
>> latest that arrived between the moment you submitted a request to the
>> device and the moment you are ready submit a new one.
>
>
> So your suggestion is to only keep a single item in the queue?

That would not be a queue anymore, but essentially yes. Store pending
brightness and FF effect in the driver structure and simply replace it
with the latest requests until the device is ready to process next
request. You need to take care alternating serving LED vs FF requests
to make sure one does not starve another.

Thanks!

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web