Date: Mon, 26 Jul 2004 16:17:00 -0400 From: James <haesu@towardex.com> To: Don Bowman <don@sandvine.com> Cc: 'James' <haesu@towardex.com> Subject: Re: device polling takes more CPU hits?? Message-ID: <20040726201700.GA5305@scylla.towardex.com> In-Reply-To: <FE045D4D9F7AED4CBFF1B3B813C85337051D9441@mail.sandvine.com> References: <FE045D4D9F7AED4CBFF1B3B813C85337051D9441@mail.sandvine.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Don, > Hmm, this is more interesting. > Since you are SMP, and using POLLING, i assume you did > like me and commented out the !POLLING in SMP #error statement. Yep. Otherwise kernel won't compile ;-) > You definitely want the halt on idle. The polling in idle > doesn't work anyway, so try disabling it. Yea, I made sure cpu_idle_hlt set to 1, and also made sure polling.idle_poll is set to 0. Then turned on device polling again.. CPU load again goes higher.. I then tried setting burst_max to 1000 and each_burst to 80, hence duplicating the parameters you are using on your system. The CPU load then went down, but its still not any lower than running it w/o device polling at all (meaning, device polling still isn't working properly). I have two boxes behind em0 that I can use to generate 250kpps to another vlan within em0 card as a test, so that bge0 is not involved in the stress test. Even when doing so, CPU load climbs higher with device polling turned on. Opened up systat, etc to check the interrupts, and em0 is generating 0 interrupts with device polling on (as obvious), but general interrupt load climbs rock high.. so I don't know what's causing it to climb. Cleared the firewall rules as well as a test... no difference :( Oh also, just FYI, each vlan interface has link0 set, since em(4) supports hardware 802.1q tag/detagging. Thanks! -J -- James Jun TowardEX Technologies, Inc. Technical Lead Network Design, Consulting, IT Outsourcing james@towardex.com Boston-based Colocation & Bandwidth Services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040726201700.GA5305>