From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 14 02:14:14 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34E81688 for ; Fri, 14 Feb 2014 02:14:14 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C05D61D78 for ; Fri, 14 Feb 2014 02:14:13 +0000 (UTC) Received: from mandree.no-ip.org ([78.48.204.13]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LedVG-1VP4552qb8-00qR8r for ; Fri, 14 Feb 2014 03:14:05 +0100 Received: from [IPv6:::1] (localhost6.localdomain6 [IPv6:::1]) by apollo.emma.line.org (Postfix) with ESMTP id 6B9C923CEEB for ; Fri, 14 Feb 2014 03:14:04 +0100 (CET) Message-ID: <52FD7BEC.9050807@gmx.de> Date: Fri, 14 Feb 2014 03:14:04 +0100 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: can the scheduler decide to schedule an interrupted but runnable thread on another CPU core? What are the implications for code? References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:Rp7STEizRTaJkdGWZKyve6QWAE2hao+Wcc72N/ukzd9wqKunBl7 jDM6LYODLg48HOuI8gLivmxd/CR8QJqhhqU95pr0nsGoxgTKvLZMY7S3BEXLbmpVor9G7PZ Ui0AinI5hhl57Ej1QZnqGbRxsM0ZYwQocj6ZocSgSszTgczfx2zJDImxqxMpBt0pu/BaEv5 R3p8CDF3zvtUdtYpS7FkA== X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 02:14:14 -0000 Am 14.02.2014 00:57, schrieb Adrian Chadd: > Hi, > > Whilst digging into collisions in the flowtable code I discovered that > a bunch of them are due to some of the flowtable_lookup() code running > on a different CPU - the contention on the l2/l3 lookup lock(s) was > enough to block things so they'd get an obvious chance to be migrated. > > So this led me to wonder whether in a fully preemptive kernel, a > running kernel thread would stay on the current CPU until it hit a > very specific subset of things (exited to userland, hit a lock, etc.) > > Apparently (according to kan and rwatson) this is how we define fully > preemptive - it's not just interruptable at almost any point, but the > running task may be interrupted and rescheduled on a different CPU > outside of specific critical sections. There's one more question to ask, and that is if you have a thread that warmed up its caches and you migrate it to a different core - what happens with the execution time? It might become longer because you don't usually share or migrate the L1/L2 cache contents, so I'd naively expect lower cache hit ratios. Certainly there is not a simple answer to that, but should someone start thinking about scheduler implementations, the "setup overhead" for the switch to a different core might be relevant. (Whether it's really more than the extra effort a scheduler would require to spend to make a better decision is then yet one more question.)