On Monday 15 April 2002 22:12, Petko Manolov wrote:
> Oliver Neukum wrote:
> > And from the tasklet. Let's suppose that the atomic pool is depleted
> > and submission fails. The tasklet is scheduled. Unless another tasklet
> > or interrupt frees the right kind of memory the tasklet will keep
> > r
On Monday 15 April 2002 19:36, Petko Manolov wrote:
> > Yes, you are right.
> > Next issue. What prevents you from burning all available CPU ?
>
> The tasklet is rescheduled unconditionaly only from the Rx callback.
> No Rx packets, no overkill.
And from the tasklet. Let's suppose that the atomic
Oliver Neukum wrote:
> And from the tasklet. Let's suppose that the atomic pool is depleted
> and submission fails. The tasklet is scheduled. Unless another tasklet
> or interrupt frees the right kind of memory the tasklet will keep
> rescheduling itself.
That's what we want, isn't it?
> Yes, you are right.
> Next issue. What prevents you from burning all available CPU ?
The tasklet is rescheduled unconditionaly only from the Rx callback.
No Rx packets, no overkill.
Petko
___
[EMAIL PROTECTED]
To unsubscribe, use th
> > 5. You do not lock against concurrent tasklets. IMHO with sufficiently
> > bad luck two tasklets can try to submit the rx urb at the same time.
>
> Nope. It is one tasklet and one tasklet is never run on two CPUs at
> once even on SMP machine. Quote from Rusty's Unreliable Guide to Kernel
>
Oliver Neukum wrote:
> On Friday 12 April 2002 20:01, Petko Manolov wrote:
>
> pool, the tasklet will not be scheduled a second time, as
> only the completion handler will reliably schedule the tasklet.
Fixed.
> 5. You do not lock against concurrent tasklets. IMHO with sufficiently
> bad luck t
On Friday 12 April 2002 20:01, Petko Manolov wrote:
> > IMHO draining the pool about 50% and then refill it in
> > one go would be much more efficient.
>
> The pool doesn't change the efficiency. At all. I tested the driver
> with and without rx skb cache and there was no difference. Looks like
> 3. The handling for errors in urb->status in the rx path looks fishy.
> There's a code path in which you don't schedule the tasklet.
It turned out returning on -ENOENT is the right thing. This error code
mean the urb is in unlink stage and no action is required. :-)
Petko
_
> IMHO draining the pool about 50% and then refill it in
> one go would be much more efficient.
The pool doesn't change the efficiency. At all. I tested the driver
with and without rx skb cache and there was no difference. Looks like
the bottleneck is in the usb bus itself, not in the memory a
On Friday 12 April 2002 17:17, you wrote:
> Oliver Neukum wrote:
> > On Friday 12 April 2002 02:44, you wrote:
> >>OK, this is the final patch which should cover the case we are
> >>low on memory and if usb_submit_urb() fail. Comments?
> >
> > I'd like to see the patch. Would you please include i
Oliver Neukum wrote:
> On Friday 12 April 2002 02:44, you wrote:
>
>>OK, this is the final patch which should cover the case we are
>>low on memory and if usb_submit_urb() fail. Comments?
>
>
> I'd like to see the patch. Would you please include it ? ;-)
Here we go again. :-)
Petko Manolov wrote:
> Oliver Neukum wrote:
>
>> The tasklet will safe you if you could not allocate rx_skb.
>> It will not safe you if usb_submit_urb() itself fails.
OK, this is the final patch which should cover the case we are
low on memory and if usb_submit_urb() fail. Comments?
Oliver Neukum wrote:
> The tasklet will safe you if you could not allocate rx_skb.
> It will not safe you if usb_submit_urb() itself fails.
True. Working on this.
Petko
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field a
On Thursday 11 April 2002 22:52, Petko Manolov wrote:
> > the rx urb twice, in the completion handler and in the tasklet ?
>
> Ahum, no. Rx urb is resubmited only if there is available sk_buff
> _and_ default Rx urb (dev->rx_urb) == NULL. Which is the right thing
> to do. Instead I've found pos
> the rx urb twice, in the completion handler and in the tasklet ?
Ahum, no. Rx urb is resubmited only if there is available sk_buff
_and_ default Rx urb (dev->rx_urb) == NULL. Which is the right thing
to do. Instead I've found possible memory leak in rx_fixup after
looking at ti closely. :-)
15 matches
Mail list logo
