From owner-freebsd-current@FreeBSD.ORG  Wed Feb 19 19:51:24 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@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 5E9F055F;
 Wed, 19 Feb 2014 19:51:24 +0000 (UTC)
Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com
 [IPv6:2607:f8b0:400d:c00::229])
 (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
 (No client certificate requested)
 by mx1.freebsd.org (Postfix) with ESMTPS id DDC181CE4;
 Wed, 19 Feb 2014 19:51:23 +0000 (UTC)
Received: by mail-qa0-f41.google.com with SMTP id w8so1344476qac.14
 for <multiple recipients>; Wed, 19 Feb 2014 11:51:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:sender:in-reply-to:references:date:message-id:subject
 :from:to:cc:content-type;
 bh=X6kNn5lN+MC2b63xQb/SfNCqkKNbURa6SF3LWah8+hM=;
 b=IUOmYzcb7wLTInvCC1V1jalVn7UgVmahUDExLmX+ixc3pht1YXyAk7Nb983zbylxUl
 GqzhoEwPiiuVO1d+fc0Pr/jE+Okv/9SJhiozFpHoc2kk9KASrSgLJm/5kov7rFkjlnh+
 /JH9GuZ8EP69a90BltAh1Vv18iaqsOVjU9W7lZ0eWCRYEnYBkBnUBJUXt7PxvYiThsct
 OYfk1XUeQyJc1B7cOOLmD37QbI9wpQaiYLpctDetIWGXIn2S0bcWxrOpULRTXOe+iy5B
 rTC3PgKD0G+fBFH4UMMwOzyDZLKHgrK2MgDzWh/vMRdHz4rloBvlRKpx58nrsT+Bu8qh
 7j6g==
MIME-Version: 1.0
X-Received: by 10.224.121.137 with SMTP id h9mr53542985qar.55.1392839483145;
 Wed, 19 Feb 2014 11:51:23 -0800 (PST)
Sender: adrian.chadd@gmail.com
Received: by 10.224.16.10 with HTTP; Wed, 19 Feb 2014 11:51:23 -0800 (PST)
In-Reply-To: <530508B7.7060102@FreeBSD.org>
References: <530508B7.7060102@FreeBSD.org>
Date: Wed, 19 Feb 2014 11:51:23 -0800
X-Google-Sender-Auth: GGQpyPjUteZDH3ufNKQq0jlXsgk
Message-ID: <CAJ-VmokQ_C=YVpk41_r-QakB46_RWRe0didq1_RrZBMS7hDX-A@mail.gmail.com>
Subject: Re: [rfc] bind per-cpu timeout threads to each CPU
From: Adrian Chadd <adrian@freebsd.org>
To: Alexander Motin <mav@freebsd.org>
Content-Type: text/plain; charset=ISO-8859-1
Cc: Jeffrey Faden <jeffreyatw@gmail.com>,
 freebsd-current <freebsd-current@freebsd.org>,
 "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
 <freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>, 
 <mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
 <mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Feb 2014 19:51:24 -0000

On 19 February 2014 11:40, Alexander Motin <mav@freebsd.org> wrote:
> Hi.
>
> Clock interrupt threads, same as other ones are only softly bound to
> specific CPUs by scheduler preferring to run them on CPUs where they are
> scheduled. So far that was enough to balance load, but allowed threads to
> migrate, if needed. Is it too flexible for some use case?

I saw it migrate under enough CPU load / pressure, right smack bang in
the middle of doing TCP processing.

So if we're moving towards supporting (among others) a pcbgroup / RSS
hash style work load distribution across CPUs to minimise
per-connection lock contention, we really don't want the scheduler to
decide it can schedule things on other CPUs under enough pressure.
That'll just make things worse.


-a