Hi Peter, On Thu, Aug 18, 2011 at 3:12 PM, Peter Hurley <peter@xxxxxxxxxxxxxxxxxx> wrote: > Thanks. Yes, in the current scheduler a connection can be scheduled > multiple times per tasklet run. > > For example, supposed that acl_cnt == 3 and 2 connections have packets > in their queue. Let's assume for the sake of simplicity that no > connections currently have unacked packets (c->sent == 0). Then (with > the current scheduler), > > 1st iteration: conn list walked => conn A found (equal unacked) > quote = 3/2 => 1 for conn A > conn A now has 1 unacked packet (after send) > > 2nd iteration: conn list walked => conn B found (lowest unacked) > quote = 2/2 => 1 for conn B > conn B now has 1 unacked packet (after send) > > 3rd iteration: conn list walked => conn A found (equal unacked) > quote = 1/2 => 1 for conn A > conn A now has 2 unacked packets (after send) > > With the proposed change, only 2 iterations occur: > > 1st iteration: conn list walked => conn A found (equal unacked) > quote = 3/2 => 2 for conn A > conn A now has 2 unacked packets (after send) > > 2nd iteration: conn list walked => conn B found (lowest unacked) > quote = 1/2 => 1 for conn B > conn B now has 1 unacked packet (after send) > > However, even with this change it may be that connections are scheduled > multiple times per tasklet. This can happen if a connection still has > equal or fewer unacked packets even after spending it's quota. > > But I didn't see in your proposal where you assume that an HCI channel > can only be scheduled once (or at least where it breaks down if true). My last patch checks if a channel has already sent any data in the current task and skip if it did (note that chan->sent != conn->sent), I was trying to reduce the complexity but it seems it breaks the logic with unacked packets. -- Luiz Augusto von Dentz -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
