[RFC v2 2/5] Bluetooth: Minor optimization for multiple tx connections

[RFC v2 2/5] Bluetooth: Minor optimization for multiple tx connections

[Peter Hurley]

V2hlbiBhc3NpZ25pbmcgdHggcXVvdGFzIGZvciBtdWx0aXBsZSBjb25uZWN0aW9ucywgYnVtcCBm
cmFjdGlvbmFsDQphbW91bnRzIHRvIHRoZSBuZXh0IGhpZ2hlciBpbnRlZ2VyLiBUaGlzIGNhbiBy
ZWR1Y2UgdGhlIG51bWJlciBvZg0KaXRlcmF0aW9ucyB0aHJvdWdoIHRoZSB0eCBzY2hlZHVsZXIu
IEZvciBleGFtcGxlLCBpZiA1IGF2YWlsIGFjbA0KYnVmZmVycyBhcmUgdG8gYmUgdXNlZCBieSAz
IHRyYW5zbWl0dGluZyBjb25uZWN0aW9ucywgdGhlIGN1cnJlbnQNCnNjaGVkdWxlciB3aWxsIHBy
b2R1Y2UgcXVvdGFzIG9mIDEsIDEsIDEsIDEsIDEuIFRoaXMNCm9wdGltaXphdGlvbiB3aWxsIGlu
c3RlYWQgcHJvZHVjZSBxdW90YXMgb2YgMiwgMiwgMSAoaWUuLCAyIGxlc3MNCml0ZXJhdGlvbnMg
b2YgdGhlIHR4IHNjaGVkdWxlcikuDQoNClNpZ25lZC1vZmYtYnk6IFBldGVyIEh1cmxleSA8cGV0
ZXJAaHVybGV5c29mdHdhcmUuY29tPg0KLS0tDQogbmV0L2JsdWV0b290aC9oY2lfY29yZS5jIHwg
ICAgNSArKy0tLQ0KIDEgZmlsZXMgY2hhbmdlZCwgMiBpbnNlcnRpb25zKCspLCAzIGRlbGV0aW9u
cygtKQ0KDQpkaWZmIC0tZ2l0IGEvbmV0L2JsdWV0b290aC9oY2lfY29yZS5jIGIvbmV0L2JsdWV0
b290aC9oY2lfY29yZS5jDQppbmRleCA0N2EzMWZhLi4wZGVmYTgzIDEwMDY0NA0KLS0tIGEvbmV0
L2JsdWV0b290aC9oY2lfY29yZS5jDQorKysgYi9uZXQvYmx1ZXRvb3RoL2hjaV9jb3JlLmMNCkBA
IC0xODI2LDcgKzE4MjYsNyBAQCBzdGF0aWMgaW5saW5lIHN0cnVjdCBoY2lfY29ubiAqaGNpX2xv
d19zZW50KHN0cnVjdCBoY2lfZGV2ICpoZGV2LCBfX3U4IHR5cGUsIGludA0KIAl9DQogDQogCWlm
IChjb25uKSB7DQotCQlpbnQgY250LCBxOw0KKwkJaW50IGNudDsNCiANCiAJCXN3aXRjaCAoY29u
bi0+dHlwZSkgew0KIAkJY2FzZSBBQ0xfTElOSzoNCkBAIC0xODQ0LDggKzE4NDQsNyBAQCBzdGF0
aWMgaW5saW5lIHN0cnVjdCBoY2lfY29ubiAqaGNpX2xvd19zZW50KHN0cnVjdCBoY2lfZGV2ICpo
ZGV2LCBfX3U4IHR5cGUsIGludA0KIAkJCUJUX0VSUigiVW5rbm93biBsaW5rIHR5cGUiKTsNCiAJ
CX0NCiANCi0JCXEgPSBjbnQgLyBudW07DQotCQkqcXVvdGUgPSBxID8gcSA6IDE7DQorCQkqcXVv
dGUgPSAoY250ICsgKG51bSAtIDEpKSAvIG51bTsNCiAJfSBlbHNlDQogCQkqcXVvdGUgPSAwOw0K
IA0KLS0gDQoxLjcuNC4xDQoNCg==

Re: [RFC v2 2/5] Bluetooth: Minor optimization for multiple tx connections

[Luiz Augusto von Dentz]

Hi Peter,

On Thu, Aug 18, 2011 at 3:37 AM, Peter Hurley <peter@hurleysoftware.com> wrote:
> When assigning tx quotas for multiple connections, bump fractional
> amounts to the next higher integer. This can reduce the number of
> iterations through the tx scheduler. For example, if 5 avail acl
> buffers are to be used by 3 transmitting connections, the current
> scheduler will produce quotas of 1, 1, 1, 1, 1. This
> optimization will instead produce quotas of 2, 2, 1 (ie., 2 less
> iterations of the tx scheduler).
>
> Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
> ---
>  net/bluetooth/hci_core.c |    5 ++---
>  1 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> index 47a31fa..0defa83 100644
> --- a/net/bluetooth/hci_core.c
> +++ b/net/bluetooth/hci_core.c
> @@ -1826,7 +1826,7 @@ static inline struct hci_conn *hci_low_sent(struct hci_dev *hdev, __u8 type, int
>        }
>
>        if (conn) {
> -               int cnt, q;
> +               int cnt;
>
>                switch (conn->type) {
>                case ACL_LINK:
> @@ -1844,8 +1844,7 @@ static inline struct hci_conn *hci_low_sent(struct hci_dev *hdev, __u8 type, int
>                        BT_ERR("Unknown link type");
>                }
>
> -               q = cnt / num;
> -               *quote = q ? q : 1;
> +               *quote = (cnt + (num - 1)) / num;
>        } else
>                *quote = 0;
>
> --
> 1.7.4.1
>

Nice catch, actually after seeing your patch I realize one of my
patches is wrong in assuming an HCI Channel can only be scheduled once
per tx_task, but I guess with your changes we can probably assume so,
right?


-- 
Luiz Augusto von Dentz

Re: [RFC v2 2/5] Bluetooth: Minor optimization for multiple tx connections

[Luiz Augusto von Dentz]

Hi Peter,

On Thu, Aug 18, 2011 at 3:12 PM, Peter Hurley <peter@hurleysoftware.com> 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