netdev - Re: [PATCH] net: gen_estimator: Fix gen_kill

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20081124133724.GC16755@ff.dom.local>
Date:	Mon, 24 Nov 2008 13:37:24 +0000
From:	Jarek Poplawski <jarkao2@...il.com>
To:	hadi@...erus.ca
Cc:	David Miller <davem@...emloft.net>,
	Badalian Vyacheslav <slavon@...telecom.ru>,
	Denys Fedoryshchenko <denys@...p.net.lb>,
	netdev@...r.kernel.org
Subject: Re: [PATCH] net: gen_estimator: Fix gen_kill_estimator() lookups

On Mon, Nov 24, 2008 at 08:18:45AM -0500, jamal wrote:
> On Mon, 2008-11-24 at 12:04 +0000, Jarek Poplawski wrote:
> > gen_kill_estimator() linear lists lookups are very slow, and e.g. while
> > deleting a large number of HTB classes soft lockups were reported. Here
> > is another try to fix this problem: this time internally, with rbtree,
> > so similarly to Jamal's hashing idea IIRC. (Looking for next hits could
> > be still optimized, but it's really fast as it is.)
> 
> Certainly a big improvement. Compared to hashing i suggested:
> the deletion speed is probably equal or better than using a hash.
> I think a hash would have performed better in the case of addition
> than the rb tree; but you primarily concerned about deletion, so this
> good.

I first thought about a hash, but alas Patrick's solution is sched
only... Anyway, I din't see too much overhead in memory use, and no
diffrence in addition times (without batching).

> 
> Acked-by: Jamal Hadi Salim <hadi@...erus.ca>
> 

Thanks,
Jarek P.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html