From: Patrick McHardy <kaber@trash.net>
To: devik <devik@cdi.cz>
Cc: "David S. Miller" <davem@redhat.com>,
hadi@cyberus.ca, netdev@oss.sgi.com, tomasz.paszkowski@e-wro.pl
Subject: Re: Fw: hfsc and huge set of rules
Date: Sun, 01 Aug 2004 19:56:04 +0200 [thread overview]
Message-ID: <410D2EB4.1060205@trash.net> (raw)
In-Reply-To: <Pine.LNX.4.33.0407301752250.1421-100000@devix>
devik wrote:
>Also IIRC class lookup is done before each remove. With
>hashing size a few tens of buckets the complexity
>starts to be very near to O(n^2).
>
>
I think the hash size of HTB, HFSC and CBQ should be increased,
the hash function performs well even with 2^16. With HFSC using
many classes doesn't scale well right now, but with the rbtree patches
it will.
Regards
Patrick
>devik
>
>On Fri, 30 Jul 2004, Patrick McHardy wrote:
>
>
>
>>David S. Miller wrote:
>>
>>
>>>Looks like qdisc destruction has some expensive algorithms.
>>>Any quick ideas about the root culprit at least in the hfsc
>>>case? He says htb does it too.
>>>
>>>
>>hfsc_destroy_qdisc takes O(n) time wrt. the number of classes,
>>but 5-6 seconds is still long. If all these classes contain inner
>>qdiscs other than the default, I guess removing the classes from
>>dev->qdisc_list in qdisc_destroy takes up most of the time, with
>>n O(n) operations. The __qdisc_destroy rcu callback also calls
>>reset before destroy, I don't know any qdisc where this is really
>>neccessary. Without inner qdiscs, I need to see the script first to
>>judge what's going wrong. Tomasz ?
>>
>>
prev parent reply other threads:[~2004-08-01 17:56 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-30 4:18 Fw: hfsc and huge set of rules David S. Miller
2004-07-30 10:34 ` Patrick McHardy
2004-07-30 11:08 ` Tomasz Paszkowski
2004-07-30 20:38 ` jamal
2004-08-01 17:53 ` Patrick McHardy
2004-08-04 9:14 ` Tomasz Paszkowski
2004-07-30 15:54 ` devik
2004-08-01 17:56 ` Patrick McHardy [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=410D2EB4.1060205@trash.net \
--to=kaber@trash.net \
--cc=davem@redhat.com \
--cc=devik@cdi.cz \
--cc=hadi@cyberus.ca \
--cc=netdev@oss.sgi.com \
--cc=tomasz.paszkowski@e-wro.pl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.