From owner-freebsd-arch@FreeBSD.ORG Thu Nov 23 06:53:40 2006 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from localhost.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 7BE8516A403; Thu, 23 Nov 2006 06:53:40 +0000 (UTC) (envelope-from davidxu@freebsd.org) From: David Xu To: Bruce Evans Date: Thu, 23 Nov 2006 14:53:33 +0800 User-Agent: KMail/1.8.2 References: <200611231205.55629.davidxu@freebsd.org> <20061123170941.T36132@delplex.bde.org> In-Reply-To: <20061123170941.T36132@delplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200611231453.34287.davidxu@freebsd.org> Cc: arch@freebsd.org, Kip Macy , Alan Cox , freebsd-arch@freebsd.org Subject: Re: superpage plans X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Nov 2006 06:53:41 -0000 On Thursday 23 November 2006 14:28, Bruce Evans wrote: > On Thu, 23 Nov 2006, David Xu wrote: > > On Thursday 23 November 2006 11:25, Bruce Evans wrote: > >> On Wed, 22 Nov 2006, Alan Cox wrote: > >>> There is only one caveat. Idle-time page prezeroing is not supported. > >>> However, ever since the VM system emerged from the Giant kernel lock, > >>> I've seen little or no benefit from it. ... > >> > >> That's probably because PREEMPTION is broken and the brokenness turns > >> idle-time page prezeroing into a pessimization. Without PREEMPTION I > >> see much the same benefits from idle-time page prezeroing as in RELENG_4 > >> -- a speedup of a few percent for makeworld. E.g., for makeworld -j4 > > > > I think on SMP, the BSD scheduler code does not preempt an idle > > thread in remote cpu, this might explain the reason why page_zero > > uses much time on SMP. the maybe_preempt() only works > > for current cpu. > > See my previous mail to freebsd-arch about this. IPI_PREEMPTION should > result in preempting pgzero, but doesn't seem to, and if it did then > you would wish it wouldn't since it has larger overheads than voluntarility > giving up control. For user idle threads, there is nothing better > than sending an IPI, but pgzero does a good job of limiting itself so > preempting it just pessimizes it. Even non-IPI preemption will sometimes > have higher overheads. > > Bruce Do you really believe IPI_PREEMPTION works as expected ? the problem is in sched_4bsd.c, the remote cpu running an idle cpu is only interrupted by IPI_AST not IPI_PREEMPT, IPI_AST has no effect for kernel thread, note that kick_other_cpu is only used for bound thread which is being resumed, kick_other_cpu does send IPI_PREEMPT, though pagezero thread is a bound thread in most time, but it is not the case that kick_other_cpu will be used, we want to preempt it not resuem it, so PREEMPTION and IPI_PREEPMTION do not work for pagezero thread running on remote cpu. David Xu