netdev - Re: [PATCH] sched: Optimize return value of qdisc

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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 10 May 2007 10:12:55 -0400
From:	jamal <hadi@...erus.ca>
To:	Herbert Xu <herbert@...dor.apana.org.au>
Cc:	davem@...emloft.net, krkumar2@...ibm.com, netdev@...r.kernel.org,
	Thomas Graf <tgraf@...g.ch>, Roberto Nibali <ratz@...gphish.ch>
Subject: Re: [PATCH] sched: Optimize return value of qdisc_restart

On Thu, 2007-10-05 at 23:52 +1000, Herbert Xu wrote:
> On Thu, May 10, 2007 at 09:18:04AM -0400, jamal wrote:
> > 
> > I wonder how much performance improvement this give now that the extra
> > incursion into qdisc_restart is avoided.
> 
> Probably very little since the only way it can make a difference is if
> there is lots of contention.  But if there is lots of contention we
> should stay in the function anyway.

Less to do with CPU contention and more with Krishna's change which
avoids entering that region all together which is useful even in the
absence of contention. In the past (based on some measurement i did)
upto 50% of the executions of qdisc restart were on an empty queue
depending on traffic rates.

BTW, given that i couldnt recall the layout of the locks on qdisc
restart; I think i will come back with the old patch i had to clean up
the readability of qdisc restart so it is easy to tell just by quick
inspection.

Since Canada seems to be comfortably taking revenge on the Swiss (my
condolonces to Thomas and Ratz) - i think it is time for me to head
out ;-> ttl.

cheers,
jamal 

-
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