On Mon, Feb 05, 2007 at 06:14:13PM +0100, Simon Lodal wrote:
...
> Regards
...
It seems decisions makers need more time, so I'd add
2 cents more:
1c: an indentation could be improved (spaces around
operators), like in these places:
>+#define HTB_MAX_CLS (TC_H_MIN(-1)+1)
...
>+ ht
On Mon, Feb 05, 2007 at 06:14:13PM +0100, Simon Lodal wrote:
> On Monday 05 February 2007 11:16, Jarek Poplawski wrote:
> > On 01-02-2007 12:30, Andi Kleen wrote:
> > > Simon Lodal <[EMAIL PROTECTED]> writes:
> > >> Memory is generally not an issue, but CPU is, and you can not beat the
> > >> CPU e
On Thursday 01 February 2007 12:30, Andi Kleen wrote:
> Simon Lodal <[EMAIL PROTECTED]> writes:
> > Memory is generally not an issue, but CPU is, and you can not beat the
> > CPU efficiency of plain array lookup (always faster, and constant time).
>
> Actually that's not true when the array doesn't
On Monday 05 February 2007 11:16, Jarek Poplawski wrote:
> On 01-02-2007 12:30, Andi Kleen wrote:
> > Simon Lodal <[EMAIL PROTECTED]> writes:
> >> Memory is generally not an issue, but CPU is, and you can not beat the
> >> CPU efficiency of plain array lookup (always faster, and constant time).
>
>
Andi Kleen schrieb:
> On Monday 05 February 2007 11:16, Jarek Poplawski wrote:
> > I wonder, why not try, at least for a while, to do this
> > a compile (menuconfig) option with a comment:
> > recommended for a large number of classes. After hash
> > optimization and some testing, final decisions c
On Monday 05 February 2007 11:16, Jarek Poplawski wrote:
>
> Strange - it seems you gave only arguments against this
> analysis...
For a naturally clustered key space (as is common in this case) the two
level structure is likely more cache efficient than a generic hash function.
That is becaus
On 01-02-2007 12:30, Andi Kleen wrote:
> Simon Lodal <[EMAIL PROTECTED]> writes:
>> Memory is generally not an issue, but CPU is, and you can not beat the CPU
>> efficiency of plain array lookup (always faster, and constant time).
Probably for some old (or embedded) lean boxes used for
small netw
On Thu, 2007-01-02 at 07:08 +0100, Patrick McHardy wrote:
>
> I have a patch for HFSC which introduces dynamic resizing of the
> class hash.
One thing that has bitten me recently was tests to try and see how far i
can go insert xfrm SAD/SPDs - the resizing of the hashes kept allocing
more and m
Simon Lodal <[EMAIL PROTECTED]> writes:
>
> Memory is generally not an issue, but CPU is, and you can not beat the CPU
> efficiency of plain array lookup (always faster, and constant time).
Actually that's not true when the array doesn't fit in cache.
The cost of going out to memory over caches
On Thursday 01 February 2007 07:08, Patrick McHardy wrote:
> Simon Lodal wrote:
> > This patch changes HTB's class storage from hash+lists to a two-level
> > linear array, so it can do constant time (O(1)) class lookup by classid.
> > It improves scalability for large number of classes.
> >
> > Wit
Simon Lodal wrote:
> This patch changes HTB's class storage from hash+lists to a two-level linear
> array, so it can do constant time (O(1)) class lookup by classid. It improves
> scalability for large number of classes.
>
> Without the patch, ~14k htb classes can starve a Xeon-3.2 at only 15kpp
This patch changes HTB's class storage from hash+lists to a two-level linear
array, so it can do constant time (O(1)) class lookup by classid. It improves
scalability for large number of classes.
Without the patch, ~14k htb classes can starve a Xeon-3.2 at only 15kpps,
using most of it's cycle
12 matches
Mail list logo
