From owner-freebsd-net@FreeBSD.ORG Thu Jul 2 14:21:56 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFAF71065673 for ; Thu, 2 Jul 2009 14:21:56 +0000 (UTC) (envelope-from lab@gta.com) Received: from mailgate.gta.com (mailgate.gta.com [199.120.225.20]) by mx1.freebsd.org (Postfix) with SMTP id 408618FC14 for ; Thu, 2 Jul 2009 14:21:55 +0000 (UTC) (envelope-from lab@gta.com) Received: (qmail 78532 invoked by uid 1000); 2 Jul 2009 14:21:55 -0000 Date: Thu, 2 Jul 2009 10:21:55 -0400 From: Larry Baird To: Paul Thornton Message-ID: <20090702142155.GA71817@gta.com> References: <20090630180029.GA8847@gta.com> <4A4C9FCC.6020304@prt.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A4C9FCC.6020304@prt.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: Polling and kern.polling.idle_poll X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 14:21:57 -0000 Paul, > Larry Baird wrote: > >The man page for polling states: > > kern.polling.idle_poll > > Controls if polling is enabled in the idle loop. There are no > > reasons (other than power saving or bugs in the scheduler's han- > > dling of idle priority kernel threads) to disable this. > > > >So why is it now disabled by default? Looking back through cvs the > >change was made by Luigi way back in August of 2002. > > > > > Did you ever get a reply for this question on the -net list? I may have > missed it, but I don't think you did. > I'm very interested in why this was changed too. I got some off list mail from Luigi. In 4.x, the idle_poll() was called from idle. Now it is its own thread. CPU statistics will now show high 100% utilization if your set kern.polling.idle_poll. He also has some concerns about if locking was in place for SMP. Looking at the code locking appears to be in place. The performance improvment is too great for me to ignore, so I made a few mods to my kernels. I modified kern_poll to set P_NOLOAD for the idle_poll thread. I then modified CPU statistics to view all processes with P_NOLOAD as the idle process. So far working great for me. Patches below. *** /sys/kern/kern_poll.c 2006-06-16 18:11:55.000000000 -0400 --- kern_poll.c 2009-07-02 10:03:07.000000000 -0400 *************** *** 577,583 **** --- 577,587 ---- { struct thread *td = curthread; struct rtprio rtp; + struct proc *p = td->td_proc; + PROC_LOCK(p); + p->p_flag |= P_NOLOAD; + PROC_UNLOCK(p); rtp.prio = RTP_PRIO_MAX; /* lowest priority */ rtp.type = RTP_PRIO_IDLE; mtx_lock_spin(&sched_lock); *** /sys/kern/kern_clock.c 2008-06-04 06:31:41.000000000 -0400 --- kern_clock.c 2009-07-02 10:05:01.000000000 -0400 *************** *** 516,522 **** thread_statclock(0); td->td_sticks++; p->p_rux.rux_sticks++; ! if (td != PCPU_GET(idlethread)) { cp_time[CP_SYS]++; pcp_time[CP_SYS]++; } else { --- 516,522 ---- thread_statclock(0); td->td_sticks++; p->p_rux.rux_sticks++; ! if ( ! (p->p_flag & P_NOLOAD) ) { cp_time[CP_SYS]++; pcp_time[CP_SYS]++; } else { -- ------------------------------------------------------------------------ Larry Baird | http://www.gta.com Global Technology Associates, Inc. | Orlando, FL Email: lab@gta.com | TEL 407-380-0220, FAX 407-380-6080