From owner-freebsd-arch@FreeBSD.ORG  Fri May  9 23:49:50 2014
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@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 1D20B71D;
 Fri,  9 May 2014 23:49:50 +0000 (UTC)
Received: from alto.onthenet.com.au (alto.OntheNet.com.au [203.13.68.12])
 by mx1.freebsd.org (Postfix) with ESMTP id CF0812FD;
 Fri,  9 May 2014 23:49:49 +0000 (UTC)
Received: from dommail.onthenet.com.au (dommail.OntheNet.com.au [203.13.70.57])
 by alto.onthenet.com.au (Postfix) with ESMTPS id CAF73124BB;
 Sat, 10 May 2014 09:49:47 +1000 (EST)
Received: from Peter-Grehans-MacBook-Pro-2.local ([64.245.0.210])
 by dommail.onthenet.com.au (MOS 4.2.4-GA)
 with ESMTP id BUC14621 (AUTH peterg@ptree32.com.au);
 Sat, 10 May 2014 09:49:46 +1000
Message-ID: <536D6999.6080402@freebsd.org>
Date: Fri, 09 May 2014 16:49:45 -0700
From: Peter Grehan <grehan@freebsd.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
 rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Adrian Chadd <adrian@freebsd.org>
Subject: Re: [rfc] bind per-cpu timeout threads to each CPU
References: <530508B7.7060102@FreeBSD.org>
 <CAJ-VmonUiSeCxnbYcjtWZ8uxa0c2ys5Za_GMLQenwu8zmEuFpQ@mail.gmail.com>
 <CAJ-VmonmrB7Z-PKH7P1DOJjSvFD_nRHqaiFJUuwvHoTUtiEVoQ@mail.gmail.com>
 <201405091349.14381.jhb@freebsd.org>
 <CAJ-VmokL40MGY2=sKAtvgMBKHt6ZRY9ZfnZ1Mj5y1qAa4ANC=A@mail.gmail.com>
 <536D3184.9070302@freebsd.org>
 <CAJ-Vmom6P74kKRQezNMoznC4YGg1iYm06K=70TqLDWbeEyjyfA@mail.gmail.com>
In-Reply-To: <CAJ-Vmom6P74kKRQezNMoznC4YGg1iYm06K=70TqLDWbeEyjyfA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Alexander Motin <mav@freebsd.org>,
 freebsd-current <freebsd-current@freebsd.org>,
 "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: Discussion related to FreeBSD architecture <freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arch>,
 <mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch/>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
 <mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 09 May 2014 23:49:50 -0000

> Yup. I've just done that.
>
> http://people.freebsd.org/~adrian/norse/20140509-swi-pin-1.diff

  Thanks, that'll work.

> Which workloads are you thinking about? Maybe we could introduce some
> higher level description of which CPU(s) at boot time to do "freebsd
> stuff" on, and then don't start things like pcpu swi's and NIC threads
> on those CPUs.

  A classic case is partitioning cores into control and data plane 
groups. I'm sure there are lots more. What's nice about cpuset is that 
the choice and change can be dynamic, so long as there aren't pinned 
threads in the default set.

  An option to restrict FreeBSD pCPU threads to a subset could be useful.

> Can you think of situations where we'd want to have per-cpu swi's even
> _running_ for CPUs that you want to dedicate to other things? There's
> nothing stopping you from scheduling a callout on a different target
> CPU.

  At least for the uses I know, it's complete isolation from other 
processing, kernel threads included. The 'freebsd stuff' info you 
mentioned should be sufficient.

later,

Peter.