From owner-freebsd-arch@FreeBSD.ORG Tue Feb 18 19:58:24 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A65EA8FE; Tue, 18 Feb 2014 19:58:24 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 74C761D67; Tue, 18 Feb 2014 19:58:24 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 911BBB93B; Tue, 18 Feb 2014 14:58:23 -0500 (EST) From: John Baldwin To: Andrey Chernov Subject: Re: can the scheduler decide to schedule an interrupted but runnable thread on another CPU core? What are the implications for code? Date: Tue, 18 Feb 2014 14:42:36 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <20140215001100.GS34851@funkthat.com> <52FED14E.50304@freebsd.org> In-Reply-To: <52FED14E.50304@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Message-Id: <201402181442.36380.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 18 Feb 2014 14:58:23 -0500 (EST) Cc: "freebsd-hackers@freebsd.org" , Andriy Gapon , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 19:58:24 -0000 On Friday, February 14, 2014 9:30:38 pm Andrey Chernov wrote: > On 15.02.2014 4:11, John-Mark Gurney wrote: > >>> This is code example from cpuminer port, in case you are interested, it is very simple: > >>> > >>> static inline void affine_to_cpu(int id, int cpu) > >>> { > >>> cpuset_t set; > >>> CPU_ZERO(&set); > >>> CPU_SET(cpu, &set); > >>> cpuset_setaffinity(CPU_LEVEL_WHICH, CPU_WHICH_CPUSET, -1, sizeof(cpuset_t), &set); > >> > >> I think that CPU_WHICH_TID should have been used here. > > > > I agree... cpuset(2): > > The which argument determines how the value of id is interpreted and is > > of type cpuwhich_t. The which argument may have the following values: > > > > CPU_WHICH_TID id is lwpid_t (thread id) > > CPU_WHICH_PID id is pid_t (process id) > > CPU_WHICH_CPUSET id is a cpusetid_t (cpuset id) > > CPU_WHICH_IRQ id is an irq number > > > > An id of '-1' may be used with a which of CPU_WHICH_TID, CPU_WHICH_PID, > > or CPU_WHICH_CPUSET to mean the current thread, process, or current > > thread's cpuset. All cpuset syscalls allow this usage. > > The question still remains: why SCHED_ULE and SCHED_4BSD do different > things here on CPU_WHICH_CPUSET == -1 (current thread's cpuset)? It > looks like SCHED_ULE changes per/process mask while SCHED_4BSD change > per/thread mask in that case. Eh, no. CPU_WHICH_CPUSET changes the global set that the thread belongs to. t is not per proceses or per thread. Unless you are explicitly creating new global sets, your thread belongs to the default set (set 1), and this call is changing the default set (set 1) to only use a single CPU. This affects all processes in the machine that do not have their own sets. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Feb 19 00:28:19 2014 Return-Path: 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 458F0A0F; Wed, 19 Feb 2014 00:28:19 +0000 (UTC) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D6B4017FB; Wed, 19 Feb 2014 00:28:18 +0000 (UTC) Received: by mail-qa0-f43.google.com with SMTP id o15so24393269qap.2 for ; Tue, 18 Feb 2014 16:28:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=86PlWIGv2Q3HVdOUfhOJMWPOi6e60AbiMQ7Pg3k8ZAY=; b=P4I9B9gWB0J2AnA9h8HGSdA7QDgvPMV+Ps4zlIuN9Cbel96CyOFvcK5xWwnrRhqaHb HcOmIUVABa9l6k1qa3kTkYPpiwoNRNC0cNChyqdi2L2ZqZJgbphK0PqkOZdOmXaqkcKK PdczxEMtvPzC7RI3vekD7bX0FNPbDU5SVhqbkXDMFowQftYWwMWZHey/jWWXuUDoE42u XmS517O6uFOa3anYRfhCJjyaZOKoPj0mRg4bVJSziQqTE74+7VaQi+K+IgSD6kz+fy5Q v8bCuPcykb7jgpVehqKXUQ45W1i5Zd5AlwpoZIGP48L0d53HbZ1QtpebQkZmB+L6ULFt Ct3Q== MIME-Version: 1.0 X-Received: by 10.140.44.119 with SMTP id f110mr45202963qga.31.1392769698073; Tue, 18 Feb 2014 16:28:18 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.16.10 with HTTP; Tue, 18 Feb 2014 16:28:18 -0800 (PST) Date: Tue, 18 Feb 2014 16:28:18 -0800 X-Google-Sender-Auth: Jyth5QnZ-sb0Y0Ok-iUW5LUUVPQ Message-ID: Subject: [rfc] bind per-cpu timeout threads to each CPU From: Adrian Chadd To: "freebsd-arch@freebsd.org" , freebsd-current , Jeffrey Faden , John Baldwin Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 00:28:19 -0000 Hi, This patch binds the per-CPU timeout swi threads to the CPU they're on. The scheduler may decide that a preempted kernel thread that's still runnable and this can happen during things like per-CPU TCP timers firing. Thanks, Index: sys/kern/kern_timeout.c =================================================================== --- sys/kern/kern_timeout.c (revision 261910) +++ sys/kern/kern_timeout.c (working copy) @@ -355,6 +355,7 @@ char name[MAXCOMLEN]; #ifdef SMP int cpu; + struct intr_event *ie; #endif cc = CC_CPU(timeout_cpu); @@ -362,6 +363,11 @@ if (swi_add(&clk_intr_event, name, softclock, cc, SWI_CLOCK, INTR_MPSAFE, &cc->cc_cookie)) panic("died while creating standard software ithreads"); + if (intr_event_bind(clk_intr_event, timeout_cpu) != 0) { + printf("%s: timeout clock couldn't be pinned to cpu %d\n", + __func__, + timeout_cpu); + } #ifdef SMP CPU_FOREACH(cpu) { if (cpu == timeout_cpu) @@ -370,9 +376,15 @@ cc->cc_callout = NULL; /* Only cpu0 handles timeout(9). */ callout_cpu_init(cc); snprintf(name, sizeof(name), "clock (%d)", cpu); - if (swi_add(NULL, name, softclock, cc, SWI_CLOCK, + ie = NULL; + if (swi_add(&ie, name, softclock, cc, SWI_CLOCK, INTR_MPSAFE, &cc->cc_cookie)) panic("died while creating standard software ithreads"); + if (intr_event_bind(ie, cpu) != 0) { + printf("%s: per-cpu clock couldn't be pinned to cpu %d\n", + __func__, + cpu); + } } #endif } -a From owner-freebsd-arch@FreeBSD.ORG Wed Feb 19 00:32:33 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2C565C8A; Wed, 19 Feb 2014 00:32:33 +0000 (UTC) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BF44718A1; Wed, 19 Feb 2014 00:32:32 +0000 (UTC) Received: by mail-qa0-f47.google.com with SMTP id j5so24134043qaq.6 for ; Tue, 18 Feb 2014 16:32:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=hWdgO78LqGdWyDPtpK3tohGE9sr642FLCGSM3sP1ynQ=; b=gqYRwofj2B+yw60Qpeiqogb72VnusKBCuAje7FtGOvzpN7PdREsfXg8eVEpPWIi2dR nFVFlEuRET7hbnu7Pieg7Xrmt60SNGUAadT6lDvv+KsLDqkB9JJrtFEJ8FEthYf/OzJ+ 1Zl3LYqQKGFS8OxNSjJHdvDSmBfJHCFh26m01L8DrHRGq+VGNOkthgNhkttNdqAQN+Dz FQ3aqjmJZ7WPjx8hCBIZ3a9lUJYy8iCZpuzzGHyu0wVNl7yrc9PFWrOZuHa8dKyKV1tt rG6Uki6SOGX6UsMFfRCSxDNKJXmD0J3U9qmYOlXJ+hZqcARuIpKLC6QHcgnQPiEJ35hz sWPA== MIME-Version: 1.0 X-Received: by 10.224.125.4 with SMTP id w4mr15512371qar.68.1392769952037; Tue, 18 Feb 2014 16:32:32 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.16.10 with HTTP; Tue, 18 Feb 2014 16:32:32 -0800 (PST) Date: Tue, 18 Feb 2014 16:32:32 -0800 X-Google-Sender-Auth: intH1abbjtVTQYc-V8ubSaTK7o8 Message-ID: Subject: [rfc] add callgraph PC annotation to pmcstat From: Adrian Chadd To: "freebsd-arch@freebsd.org" , freebsd-current , George Neville-Neil Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 00:32:33 -0000 Hi, This patch adds callgraph annotation to pmcstat via -a. It doesn't (yet) add line numbers; I'll see if I can easily add that without too much effort. This is like (and based on) the -m option but the -m option only prints the first entry in the callgraph. It isn't very useful if you want to see what actually called it and where it called it from, in order to trace things like "where's that memcpy actually coming from?" http://people.freebsd.org/~adrian/netflix/20140218-pmcstat-callgraph-annotate.diff Thanks! -a From owner-freebsd-arch@FreeBSD.ORG Wed Feb 19 00:46:02 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 019461E8; Wed, 19 Feb 2014 00:46:02 +0000 (UTC) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8E6E8197C; Wed, 19 Feb 2014 00:46:01 +0000 (UTC) Received: by mail-qg0-f49.google.com with SMTP id j107so8193084qga.8 for ; Tue, 18 Feb 2014 16:46:00 -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:content-type; bh=HLN2VtLhpX6ANeRJNTIdtERhNAOSAyXpo7Hpeo3afqs=; b=SRILzV8NgG1gVv0LAMFdElkvY8VKYVa1zR13Ffcq+SWyS6XHJOUJeCOPQ2Xa1zQewK qZ4wXledKsf0cmCJTz2FzNOTSXIcohz85mNBp/jNWb0yG6MHbAOC63//3P9iYnLs+o/5 xKRl534tqDvxxlw4cuazPyx/6UJFc/RpsQ1ZuzZol7Y68z38nQJ2pzja6/0SSDtf7lOM moJRih51bhrN53KMfch2/ZBi1gQzb2YtY128eJ2xHKFGOofMD6htthUnZ7ebEVMBHt8t BG4pLFmHg1Ytnp7SubOkqQDgUBnz6zCD2W2467Ettvw50sUZI8jDSdjext4r+plPPFNV WitA== MIME-Version: 1.0 X-Received: by 10.140.22.145 with SMTP id 17mr45127973qgn.0.1392770760430; Tue, 18 Feb 2014 16:46:00 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.16.10 with HTTP; Tue, 18 Feb 2014 16:46:00 -0800 (PST) In-Reply-To: References: Date: Tue, 18 Feb 2014 16:46:00 -0800 X-Google-Sender-Auth: QjHyLFxXwCanUaSFqCV0OEmioZ4 Message-ID: Subject: Re: [rfc] add callgraph PC annotation to pmcstat From: Adrian Chadd To: "freebsd-arch@freebsd.org" , freebsd-current , George Neville-Neil Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 00:46:02 -0000 .. and now with file:line information: http://people.freebsd.org/~adrian/netflix/20140218-pmcstat-callgraph-annotate-2.diff It doesn't yet correctly handle klds - the address calculation stuff isn't taking the load addr into account. -a From owner-freebsd-arch@FreeBSD.ORG Wed Feb 19 12:17:23 2014 Return-Path: Delivered-To: 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 9144AE49 for ; Wed, 19 Feb 2014 12:17:23 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 73D78103E for ; Wed, 19 Feb 2014 12:17:23 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s1JCHNZD012488 for ; Wed, 19 Feb 2014 12:17:23 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s1JCHNdU012487 for arch@freebsd.org; Wed, 19 Feb 2014 12:17:23 GMT (envelope-from bdrewery) Received: (qmail 23924 invoked from network); 19 Feb 2014 06:17:19 -0600 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 19 Feb 2014 06:17:19 -0600 Message-ID: <5304A0CC.5000505@FreeBSD.org> Date: Wed, 19 Feb 2014 06:17:16 -0600 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: arch@freebsd.org Subject: terminfo X-Enigmail-Version: 1.6 OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="E22HQx5xIxOg4AxrHklm8sC0MCAVa0xvd" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 12:17:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --E22HQx5xIxOg4AxrHklm8sC0MCAVa0xvd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Why do we not use terminfo? Our termcap is quite aged and missing a lot of modern terminals/clients. Using terminfo would allow us to use the already well maintained database from ncurses. Is it just a matter of someone doing the work or are there other reasons?= --=20 Regards, Bryan Drewery --E22HQx5xIxOg4AxrHklm8sC0MCAVa0xvd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTBKDMAAoJEDXXcbtuRpfP7dYH/Rdl/gTjK4o4EhdKv9Y26ofh KbsuPkNUmvvZGpHS4nk5SlWPvUMYxGpzcZApBOJ4Vm9KblqaKVEjRnhD6ARmS0R3 8k3BmN/zPiLv0gKlcLj/quR/9JNnXL8qBQxxia7PR4tO6U8DA5UBIYVlnxwyVvoI p0ZIJvm8PivO67fa4OimyQe4JFuodBqHLX7iB6jOEY7+88LfNBFmHCraHoMxCP/O +J7yCZSvLSPFOe9voQfZ4Q+cok8g2487M50PV5kbnQ34H4ZgturSwROYzUQjYksV pvXc3Fi3FSK8Px8jsG0rO48bXybeiczYKrGuiArC62y/lznfiWgHsGb/vfKYuoI= =N1YJ -----END PGP SIGNATURE----- --E22HQx5xIxOg4AxrHklm8sC0MCAVa0xvd-- From owner-freebsd-arch@FreeBSD.ORG Wed Feb 19 14:29:11 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 05B7C69A for ; Wed, 19 Feb 2014 14:29:11 +0000 (UTC) Received: from mail-ee0-f50.google.com (mail-ee0-f50.google.com [74.125.83.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8866E1B9F for ; Wed, 19 Feb 2014 14:29:10 +0000 (UTC) Received: by mail-ee0-f50.google.com with SMTP id d17so272145eek.9 for ; Wed, 19 Feb 2014 06:29:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=W0US+w0x6u6POCX2XTbaBmHCHIP5dBWyf5nzM/WiwuA=; b=Spoti5jWl4iTnnNyeTPs25qXaxiCvS+r3v6zq4ggMatnHWzZdGL+tTslxCVYRIyLJP iMTJXFtovlYi2upX2G9Lnc4ji1ddm0m9xon1gHY+ELrSTFdAVlxR1E+rRwYDZ7tT6Q70 Bj0UP72m012jcjvtPtupw7o9YK7/1w67FgJcmWOgw1ZDkTj7Uoo/y/dSwTvqOQevQse1 weIUeE90cG1QWDEig8ZkJY/EKzF9i447/Vre2dePNinEs6AOIeQu+Qb1a6XTKwXFvJAT XJgMZG0n/rFqnfrz5QqWfsLyLHRFLVyC2KvKFcQ4TIBMQXThHqBKuZ1LQacmrYpSXE9d qj9A== X-Gm-Message-State: ALoCoQmh5Y/orAVBGXvPY0RtONd2ynSDL6xFpTi+eusoQUU/HhEZ3jhJNgfaV8Z+cNfhNZpeXkZi X-Received: by 10.15.98.68 with SMTP id bi44mr15243103eeb.67.1392820143279; Wed, 19 Feb 2014 06:29:03 -0800 (PST) Received: from [192.168.1.2] ([89.169.173.68]) by mx.google.com with ESMTPSA id j42sm1290703eep.21.2014.02.19.06.29.02 for (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Feb 2014 06:29:02 -0800 (PST) Message-ID: <5304BFAD.50502@freebsd.org> Date: Wed, 19 Feb 2014 18:29:01 +0400 From: Andrey Chernov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: John Baldwin Subject: Re: can the scheduler decide to schedule an interrupted but runnable thread on another CPU core? What are the implications for code? References: <20140215001100.GS34851@funkthat.com> <52FED14E.50304@freebsd.org> <201402181442.36380.jhb@freebsd.org> In-Reply-To: <201402181442.36380.jhb@freebsd.org> X-Enigmail-Version: 1.7a1pre Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" , Andriy Gapon , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 14:29:11 -0000 On 18.02.2014 23:42, John Baldwin wrote: > Eh, no. CPU_WHICH_CPUSET changes the global set that the thread belongs to. > t is not per proceses or per thread. Unless you are explicitly creating > new global sets, your thread belongs to the default set (set 1), and this > call is changing the default set (set 1) to only use a single CPU. This > affects all processes in the machine that do not have their own sets. > Thanx for detailed explanation. According to it, SCHED_ULE does the right thing for such CPU_WHICH_CPUSET call, while SCHED_4BSD does not. Is recent r260043 supposed to fix the problem for SCHED_4BSD or is it unrelated? I can't check it by myself yet. -- http://ache.vniz.net/ From owner-freebsd-arch@FreeBSD.ORG Wed Feb 19 19:40:45 2014 Return-Path: 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 8B5C2C28; Wed, 19 Feb 2014 19:40:45 +0000 (UTC) Received: from mail-ee0-x22b.google.com (mail-ee0-x22b.google.com [IPv6:2a00:1450:4013:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 96B881BE6; Wed, 19 Feb 2014 19:40:44 +0000 (UTC) Received: by mail-ee0-f43.google.com with SMTP id e51so340686eek.30 for ; Wed, 19 Feb 2014 11:40:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=AJWRW5BvtIktqLdiSbIGQr6fS9n54lzMsUVK+6xN5Zc=; b=J2Aj/ogk3gD7gbHvR8ldQBLA6TVvbaVn+d9LyCcbIu3FVL+auq2f6/FVA5dwx2GqgR m+vodjW8gsxFTwOm+zKNlPmuNQkBUrD/1RMNRgm1ZvT27o+muX763UgD7SHw6oEVZ/TS azGZMjDPz8Icn5Vk17OHuwbId3nmObpcnqm5d284aEYzd4cjNZ7WpfmUVrG4hiIXxkwa 43RXHmUDxd0tFGP/ffrspP6fZGLE+mwI7GPOlUgiCTsD2FyrJIxSyReMZsger19Tp4id S8SB4l/T4YpdNYiKiNy0xuEEM53QmJD2DruwSpo4SvqymkhXteMXZtbKC0s52pDXlFM2 vA3g== X-Received: by 10.14.149.131 with SMTP id x3mr41808707eej.7.1392838842978; Wed, 19 Feb 2014 11:40:42 -0800 (PST) Received: from mavbook.mavhome.dp.ua ([134.249.139.101]) by mx.google.com with ESMTPSA id f45sm4375551eeg.5.2014.02.19.11.40.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Feb 2014 11:40:41 -0800 (PST) Sender: Alexander Motin Message-ID: <530508B7.7060102@FreeBSD.org> Date: Wed, 19 Feb 2014 21:40:39 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: [rfc] bind per-cpu timeout threads to each CPU Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jeffrey Faden , freebsd-current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 19:40:45 -0000 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? -- Alexander Motin From owner-freebsd-arch@FreeBSD.ORG Wed Feb 19 19:51:24 2014 Return-Path: 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 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 ; 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: Subject: Re: [rfc] bind per-cpu timeout threads to each CPU From: Adrian Chadd To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: Jeffrey Faden , freebsd-current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 19:51:24 -0000 On 19 February 2014 11:40, Alexander Motin 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 From owner-freebsd-arch@FreeBSD.ORG Wed Feb 19 19:59:39 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7EEAD7ED; Wed, 19 Feb 2014 19:59:39 +0000 (UTC) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9B3511D43; Wed, 19 Feb 2014 19:59:38 +0000 (UTC) Received: by mail-we0-f177.google.com with SMTP id t61so712668wes.8 for ; Wed, 19 Feb 2014 11:59:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=lFoxSb/Qa7RlBFsdnMBYmMBxHLL22X+hS5e7yNG2j40=; b=mAnh1BdvWm5m2B7ENLrsS+IdrlpgyG6b6sLvdX+Tp0hWOZJK3ML9UsFAoL5Pl+JRGo zggZmv2L3iHeHIah7ikI8dmDGGBK2NtOCyWOEQjkUt52ztfbHoz9EeHTCmqmiXZIq36t q6KP3vMJNeNFxoA7yMtNDVIoob1WPMBbIv1kzRrspKSmdCWcMSO9/SJkSNML4/fNpFUy LkrB5dE1zvqrNXWoiFzQ78rzqWYe+B3j5c61MR1/VdZr2vPAfZiIMSmRSZufiu3O7Tk/ bhjk/p3eK07wvcA+ozUYJJYAvrcHXCJofRjeftwhSqY3CZRjSvRdOho2Q67Dfa4CxoFw ydbA== X-Received: by 10.15.81.196 with SMTP id x44mr41590044eey.31.1392839976375; Wed, 19 Feb 2014 11:59:36 -0800 (PST) Received: from mavbook.mavhome.dp.ua ([134.249.139.101]) by mx.google.com with ESMTPSA id o45sm4513341eeb.18.2014.02.19.11.59.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Feb 2014 11:59:35 -0800 (PST) Sender: Alexander Motin Message-ID: <53050D24.3020505@FreeBSD.org> Date: Wed, 19 Feb 2014 21:59:32 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: [rfc] bind per-cpu timeout threads to each CPU References: <530508B7.7060102@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jeffrey Faden , freebsd-current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 19:59:39 -0000 On 19.02.2014 21:51, Adrian Chadd wrote: > On 19 February 2014 11:40, Alexander Motin wrote: >> 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. True, though it is also not obvious that putting second thread on CPU run queue is better then executing it right now on another core. -- Alexander Motin From owner-freebsd-arch@FreeBSD.ORG Wed Feb 19 20:04:52 2014 Return-Path: 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 C54B0CA8; Wed, 19 Feb 2014 20:04:52 +0000 (UTC) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4F0F71E01; Wed, 19 Feb 2014 20:04:52 +0000 (UTC) Received: by mail-qc0-f175.google.com with SMTP id x13so1487713qcv.34 for ; Wed, 19 Feb 2014 12:04:51 -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=IqvWeHcGadUnOsbPLAtj5kksQ0xjEHFOAFLbQiR/TM8=; b=TXPLYIGrVzR0xx+m67xsrwLglssbQzNe8wLHxJNZ3CyuNj95JHgxcRuQV3Ugp/I+f7 UJQRytl0uUKY6LygLQydJmUs0/2A01+4LL+yqofksit5hoeVUAl6I1zcRi44DAeQEgzB XXD0PARwjac8GKAoGfv+XqPd86FT+OOy0lcZg4+v4KQQ6FOyb6hS6rrt57nhoJa/7jl4 BMXyHuo6vbYRuKF3SXHYo+g3YImZ14L2gqttsLDnYUm56972+QfaBBUDsQUhGr3KAR8z tQtrD+2K31vR7G5aipAk8iKLlz7gJy5soetOEFvww/q450aqbEWPwVVIt6uHVOWRXRvt Y7CA== MIME-Version: 1.0 X-Received: by 10.224.121.137 with SMTP id h9mr53658877qar.55.1392840291480; Wed, 19 Feb 2014 12:04:51 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.16.10 with HTTP; Wed, 19 Feb 2014 12:04:51 -0800 (PST) In-Reply-To: <53050D24.3020505@FreeBSD.org> References: <530508B7.7060102@FreeBSD.org> <53050D24.3020505@FreeBSD.org> Date: Wed, 19 Feb 2014 12:04:51 -0800 X-Google-Sender-Auth: 726LKOLQ3R1buKQFdHLdOFFrTKQ Message-ID: Subject: Re: [rfc] bind per-cpu timeout threads to each CPU From: Adrian Chadd To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: Jeffrey Faden , freebsd-current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 20:04:52 -0000 On 19 February 2014 11:59, Alexander Motin wrote: >> 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. > True, though it is also not obvious that putting second thread on CPU run > queue is better then executing it right now on another core. Well, it depends if you're trying to optimise for "run all runnable tasks as quickly as possible" or "run all runnable tasks in contexts that minimise lock contention." The former sounds great as long as there's no real lock contention going on. But as you add more chances for contention (something like "100,000 concurrent TCP flows") then you may end up having your TCP timer firing stuff interfere with more TXing or RXing on the same connection. Chasing this stuff down is a pain, because it only really shows up when you're doing lots of concurrency. I'm happy to make this a boot-time option and leave it off for the time being. How's that? -a From owner-freebsd-arch@FreeBSD.ORG Wed Feb 19 21:04:55 2014 Return-Path: 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 3CE9231B; Wed, 19 Feb 2014 21:04:55 +0000 (UTC) Received: from mail-ee0-x229.google.com (mail-ee0-x229.google.com [IPv6:2a00:1450:4013: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 5115E1445; Wed, 19 Feb 2014 21:04:54 +0000 (UTC) Received: by mail-ee0-f41.google.com with SMTP id e49so477480eek.0 for ; Wed, 19 Feb 2014 13:04:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=FB0GMNpZOBmSHQf7WepADuZcQqRlVrLrhRN+FxFJx1k=; b=x2w2ZW/RrLTiaquWqQ88uFyAedhD67Vn2LjpOFtZRb0/DRuRT3Bbzsm1P41C4EYKQr ZJRwLSJ5fsbRiOcpNfX9cbHObyfHiVC9ZW9vbgFymU94pfsLTUaRzkKjjHJ2N+/CPROA XF/UMha5q6vlQN0k9ctW6qBvAeS2LhHGN3qtvYwmDuYzNf48ltq6sKZ+7shNoFX86yhW nw/+9aY7oxmjiTTTMxk2KehuUpdkEK0c1e1XOXoApD/A0ChwsWSyyhALLmPOBz+9hsMC Jg3sFyUI2XtCr7in2wH+PmfPd2bRmVRhaW3K9uYc2TrXN9aiDlT3vJRFwgJkf3Cc9vwW u4kw== X-Received: by 10.15.98.68 with SMTP id bi44mr16976364eeb.67.1392843892638; Wed, 19 Feb 2014 13:04:52 -0800 (PST) Received: from mavbook.mavhome.dp.ua ([134.249.139.101]) by mx.google.com with ESMTPSA id u6sm5116099eep.11.2014.02.19.13.04.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Feb 2014 13:04:51 -0800 (PST) Sender: Alexander Motin Message-ID: <53051C71.3050705@FreeBSD.org> Date: Wed, 19 Feb 2014 23:04:49 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: [rfc] bind per-cpu timeout threads to each CPU References: <530508B7.7060102@FreeBSD.org> <53050D24.3020505@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jeffrey Faden , freebsd-current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 21:04:55 -0000 On 19.02.2014 22:04, Adrian Chadd wrote: > On 19 February 2014 11:59, Alexander Motin wrote: > >>> 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. > >> True, though it is also not obvious that putting second thread on CPU run >> queue is better then executing it right now on another core. > > Well, it depends if you're trying to optimise for "run all runnable > tasks as quickly as possible" or "run all runnable tasks in contexts > that minimise lock contention." > > The former sounds great as long as there's no real lock contention > going on. But as you add more chances for contention (something like > "100,000 concurrent TCP flows") then you may end up having your TCP > timer firing stuff interfere with more TXing or RXing on the same > connection. 100K TCP flows probably means 100K locks. That means that chance of lock collision on each of them is effectively zero. More realistic it could be to speak about cache coherency traffic, etc, but I still think that number of expired timeouts should be much lower then number of other flow data accesses. > Chasing this stuff down is a pain, because it only really shows up > when you're doing lots of concurrency. > > I'm happy to make this a boot-time option and leave it off for the > time being. How's that? I generally hate tunables like that. There are too few people who may even try to make grounded decision in that question. If you think it right -- just do it, otherwise -- don't do it. I am not really objecting, more like sounding concerns. -- Alexander Motin From owner-freebsd-arch@FreeBSD.ORG Wed Feb 19 21:04:59 2014 Return-Path: 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 6F5C8417; Wed, 19 Feb 2014 21:04:59 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 452531447; Wed, 19 Feb 2014 21:04:59 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5DE0BB972; Wed, 19 Feb 2014 16:04:58 -0500 (EST) From: John Baldwin To: Adrian Chadd Subject: Re: [rfc] bind per-cpu timeout threads to each CPU Date: Wed, 19 Feb 2014 16:02:54 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <530508B7.7060102@FreeBSD.org> <53050D24.3020505@FreeBSD.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201402191602.54465.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 19 Feb 2014 16:04:58 -0500 (EST) Cc: Alexander Motin , freebsd-current , Jeffrey Faden , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 21:04:59 -0000 On Wednesday, February 19, 2014 3:04:51 pm Adrian Chadd wrote: > On 19 February 2014 11:59, Alexander Motin wrote: > > >> 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. > > > True, though it is also not obvious that putting second thread on CPU run > > queue is better then executing it right now on another core. > > Well, it depends if you're trying to optimise for "run all runnable > tasks as quickly as possible" or "run all runnable tasks in contexts > that minimise lock contention." > > The former sounds great as long as there's no real lock contention > going on. But as you add more chances for contention (something like > "100,000 concurrent TCP flows") then you may end up having your TCP > timer firing stuff interfere with more TXing or RXing on the same > connection. > > Chasing this stuff down is a pain, because it only really shows up > when you're doing lots of concurrency. > > I'm happy to make this a boot-time option and leave it off for the > time being. How's that? I think having it be a tunable would be good. OTOH, I could also see another option which would be to pin all clock threads except for the "default" one by default and only have the option control whether or not the default thread is pinned to CPU 0 as callers who use callout_on() are explicitly asking to run the callout on a specific CPU. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Feb 19 21:44:29 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D74B5287; Wed, 19 Feb 2014 21:44:29 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 6395317C2; Wed, 19 Feb 2014 21:44:29 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1WGEwO-000ERU-3P; Thu, 20 Feb 2014 01:44:28 +0400 Date: Thu, 20 Feb 2014 01:44:28 +0400 From: Slawa Olhovchenkov To: Alexander Motin Subject: Re: [rfc] bind per-cpu timeout threads to each CPU Message-ID: <20140219214428.GA53864@zxy.spb.ru> References: <530508B7.7060102@FreeBSD.org> <53050D24.3020505@FreeBSD.org> <53051C71.3050705@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53051C71.3050705@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: Adrian Chadd , freebsd-current , Jeffrey Faden , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 21:44:29 -0000 On Wed, Feb 19, 2014 at 11:04:49PM +0200, Alexander Motin wrote: > On 19.02.2014 22:04, Adrian Chadd wrote: > > On 19 February 2014 11:59, Alexander Motin wrote: > > > >>> 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. > > > >> True, though it is also not obvious that putting second thread on CPU run > >> queue is better then executing it right now on another core. > > > > Well, it depends if you're trying to optimise for "run all runnable > > tasks as quickly as possible" or "run all runnable tasks in contexts > > that minimise lock contention." > > > > The former sounds great as long as there's no real lock contention > > going on. But as you add more chances for contention (something like > > "100,000 concurrent TCP flows") then you may end up having your TCP > > timer firing stuff interfere with more TXing or RXing on the same > > connection. > > 100K TCP flows probably means 100K locks. That means that chance of lock > collision on each of them is effectively zero. More realistic it could What about 100K/N_cpu*PPS timer's queue locks for remove/insert TCP timeouts callbacks? From owner-freebsd-arch@FreeBSD.ORG Wed Feb 19 22:09:11 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BAAE7BC3; Wed, 19 Feb 2014 22:09:11 +0000 (UTC) Received: from mail-ee0-x236.google.com (mail-ee0-x236.google.com [IPv6:2a00:1450:4013:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 016EE1960; Wed, 19 Feb 2014 22:09:10 +0000 (UTC) Received: by mail-ee0-f54.google.com with SMTP id e53so528383eek.27 for ; Wed, 19 Feb 2014 14:09:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=VuqIlI8+Gqs2IbN7BUiL11bTjatcrP2K8ne1jPqP2ok=; b=mZOSlh7QeZknQcNQQpBuzI5jYEnqrE+szjAtyVUHexZp3dGM40Wrk5U8CsWqz6s6Eg haW9QrRGFXPRzAPyAme8MDmhNTK7RTuzpA0RJOMbDY+RuQrYMnU1gm+bYMwdLtTflEKv 419/7GIW8dSiNpO8lUYJ7WVZBUTGH9x6rpHN0eUysHcOc7FYbxZ0SX+tAZGGC9kQ0pzc irIJsLBcTnGqfMYC2bUotyxaceELQQsR7HY84KyaaRbXUUMDVGhSBvHAgat6rcjoCK/h Dnn/H0Zaa6X68JHMGhrtrZkBKX2jHc1F9uO+hZFjq5ptNZwTuULIKLicMD8euL+c1qUZ +xtg== X-Received: by 10.14.176.66 with SMTP id a42mr4533470eem.101.1392847748155; Wed, 19 Feb 2014 14:09:08 -0800 (PST) Received: from mavbook.mavhome.dp.ua ([134.249.139.101]) by mx.google.com with ESMTPSA id 43sm3949365eeh.13.2014.02.19.14.09.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Feb 2014 14:09:07 -0800 (PST) Sender: Alexander Motin Message-ID: <53052B80.3010505@FreeBSD.org> Date: Thu, 20 Feb 2014 00:09:04 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Slawa Olhovchenkov Subject: Re: [rfc] bind per-cpu timeout threads to each CPU References: <530508B7.7060102@FreeBSD.org> <53050D24.3020505@FreeBSD.org> <53051C71.3050705@FreeBSD.org> <20140219214428.GA53864@zxy.spb.ru> In-Reply-To: <20140219214428.GA53864@zxy.spb.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , freebsd-current , Jeffrey Faden , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 22:09:11 -0000 On 19.02.2014 23:44, Slawa Olhovchenkov wrote: > On Wed, Feb 19, 2014 at 11:04:49PM +0200, Alexander Motin wrote: > >> On 19.02.2014 22:04, Adrian Chadd wrote: >>> On 19 February 2014 11:59, Alexander Motin wrote: >>> >>>>> 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. >>> >>>> True, though it is also not obvious that putting second thread on CPU run >>>> queue is better then executing it right now on another core. >>> >>> Well, it depends if you're trying to optimise for "run all runnable >>> tasks as quickly as possible" or "run all runnable tasks in contexts >>> that minimise lock contention." >>> >>> The former sounds great as long as there's no real lock contention >>> going on. But as you add more chances for contention (something like >>> "100,000 concurrent TCP flows") then you may end up having your TCP >>> timer firing stuff interfere with more TXing or RXing on the same >>> connection. >> >> 100K TCP flows probably means 100K locks. That means that chance of lock >> collision on each of them is effectively zero. More realistic it could > > What about 100K/N_cpu*PPS timer's queue locks for remove/insert TCP > timeouts callbacks? I am not sure what this formula means, but yes, per-CPU callout locks can much more likely be congested. They are only per-CPU, not per-flow. -- Alexander Motin From owner-freebsd-arch@FreeBSD.ORG Wed Feb 19 22:12:08 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8FE0BDAA; Wed, 19 Feb 2014 22:12:08 +0000 (UTC) Received: from mail-ee0-x232.google.com (mail-ee0-x232.google.com [IPv6:2a00:1450:4013:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A152219EC; Wed, 19 Feb 2014 22:12:07 +0000 (UTC) Received: by mail-ee0-f50.google.com with SMTP id d17so523292eek.23 for ; Wed, 19 Feb 2014 14:12:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=tJ+z0wA9vvFosxKZEE6CwN2Asoo2JwcjLXwXCo352hc=; b=Ll5upz2YQK0w6ppQivOM3NyoO3TdXY0t1IeH6AHY2F/4c/+dqqXfu7y0bS4qJVl3mz 8zE1ExM2nY7HPLJm58oZCYcsCij9QgFGjPE8Ynj8RK1u/aTJrKZlYbbCpyI4KlZLdT+c hgJiqzPGgyGC1FqTMfG+yhSjV8dOji+6wgl5+X+4nbq1V6DtxE4d+qQ2uhP4VykbPDXn vwKlfZIMV7Nqs/BtlY5WWNDhEEzO1c4IMcEBreBWLdOzIPcqm4TLT3CFZ7wkZNfGq7PR JM4NJLgmOlJ5A/tyITuDkYhxFQrKqD6hCP1eKIpypcAcAkNVBbgOLLdpYMPVRlA96Gmp 6tng== X-Received: by 10.14.109.71 with SMTP id r47mr42501690eeg.28.1392847925924; Wed, 19 Feb 2014 14:12:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.14.214.133 with HTTP; Wed, 19 Feb 2014 14:11:45 -0800 (PST) In-Reply-To: <53052B80.3010505@FreeBSD.org> References: <530508B7.7060102@FreeBSD.org> <53050D24.3020505@FreeBSD.org> <53051C71.3050705@FreeBSD.org> <20140219214428.GA53864@zxy.spb.ru> <53052B80.3010505@FreeBSD.org> From: Jeffrey Carl Faden Date: Wed, 19 Feb 2014 14:11:45 -0800 Message-ID: Subject: Re: [rfc] bind per-cpu timeout threads to each CPU To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-arch@freebsd.org" , Adrian Chadd , freebsd-current , Slawa Olhovchenkov X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 22:12:08 -0000 Hi guys! I was accidentally added to this thread, and would appreciate if you removed my email from any further correspondence. Thanks a bunch! Jeffrey On Wed, Feb 19, 2014 at 2:09 PM, Alexander Motin wrote: > On 19.02.2014 23:44, Slawa Olhovchenkov wrote: > >> On Wed, Feb 19, 2014 at 11:04:49PM +0200, Alexander Motin wrote: >> >> On 19.02.2014 22:04, Adrian Chadd wrote: >>> >>>> On 19 February 2014 11:59, Alexander Motin wrote: >>>> >>>> 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. >>>>>> >>>>> >>>> True, though it is also not obvious that putting second thread on CPU >>>>> run >>>>> queue is better then executing it right now on another core. >>>>> >>>> >>>> Well, it depends if you're trying to optimise for "run all runnable >>>> tasks as quickly as possible" or "run all runnable tasks in contexts >>>> that minimise lock contention." >>>> >>>> The former sounds great as long as there's no real lock contention >>>> going on. But as you add more chances for contention (something like >>>> "100,000 concurrent TCP flows") then you may end up having your TCP >>>> timer firing stuff interfere with more TXing or RXing on the same >>>> connection. >>>> >>> >>> 100K TCP flows probably means 100K locks. That means that chance of lock >>> collision on each of them is effectively zero. More realistic it could >>> >> >> What about 100K/N_cpu*PPS timer's queue locks for remove/insert TCP >> timeouts callbacks? >> > > I am not sure what this formula means, but yes, per-CPU callout locks can > much more likely be congested. They are only per-CPU, not per-flow. > > -- > Alexander Motin > From owner-freebsd-arch@FreeBSD.ORG Wed Feb 19 22:55:04 2014 Return-Path: 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 7ACA39D5; Wed, 19 Feb 2014 22:55:04 +0000 (UTC) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 108DB1D33; Wed, 19 Feb 2014 22:55:03 +0000 (UTC) Received: by mail-qa0-f45.google.com with SMTP id m5so1733696qaj.4 for ; Wed, 19 Feb 2014 14:55:03 -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=FzkE4mtRngfT55+6aMNHO5UuDsMi7jpIukJp2bb7x9U=; b=NfkaCwM8t//W5gcYCbjD6MZZXn5Y3Xb0Ul8YYIjkGTW7lArjwmUssEvApO7DcdFhxv DTfa51gQTNYD7fPmUdqnBeIRZjPVm7V5FEaaQVTWXOKW2PtCyj/lDyOJ3SmXLCSQsYE2 nzvwqGJpFY52cJhWchShmIGfw0qln/2LPeU3vi3iziqh4KKHVTSCsalN4nyDhqQG+b4p foSWxNmWPZZiGZc3Y9QRxDmbsorlS2oXeLpjNn0KF17FTUlQEhN+H/79xurqnujfOuvX vw1AxOd7f+wk+ATcVMwOXC/u5IL/9OiKOcswr4NcQ8epd2s0mEeYwOqxab+lESp2nFtA +/YA== MIME-Version: 1.0 X-Received: by 10.224.160.195 with SMTP id o3mr5218609qax.98.1392850503157; Wed, 19 Feb 2014 14:55:03 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.16.10 with HTTP; Wed, 19 Feb 2014 14:55:03 -0800 (PST) In-Reply-To: <53052B80.3010505@FreeBSD.org> References: <530508B7.7060102@FreeBSD.org> <53050D24.3020505@FreeBSD.org> <53051C71.3050705@FreeBSD.org> <20140219214428.GA53864@zxy.spb.ru> <53052B80.3010505@FreeBSD.org> Date: Wed, 19 Feb 2014 14:55:03 -0800 X-Google-Sender-Auth: PTeu-O3MZj0oEYNAg5JUlt3SFkQ Message-ID: Subject: Re: [rfc] bind per-cpu timeout threads to each CPU From: Adrian Chadd To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-arch@freebsd.org" , freebsd-current , Slawa Olhovchenkov X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 22:55:04 -0000 On 19 February 2014 14:09, Alexander Motin wrote: > On 19.02.2014 23:44, Slawa Olhovchenkov wrote: >> >> On Wed, Feb 19, 2014 at 11:04:49PM +0200, Alexander Motin wrote: >> >>> On 19.02.2014 22:04, Adrian Chadd wrote: >>>> >>>> On 19 February 2014 11:59, Alexander Motin wrote: >>>> >>>>>> 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. >>>> >>>> >>>>> True, though it is also not obvious that putting second thread on CPU >>>>> run >>>>> queue is better then executing it right now on another core. >>>> >>>> >>>> Well, it depends if you're trying to optimise for "run all runnable >>>> tasks as quickly as possible" or "run all runnable tasks in contexts >>>> that minimise lock contention." >>>> >>>> The former sounds great as long as there's no real lock contention >>>> going on. But as you add more chances for contention (something like >>>> "100,000 concurrent TCP flows") then you may end up having your TCP >>>> timer firing stuff interfere with more TXing or RXing on the same >>>> connection. >>> >>> >>> 100K TCP flows probably means 100K locks. That means that chance of lock >>> collision on each of them is effectively zero. More realistic it could >> >> >> What about 100K/N_cpu*PPS timer's queue locks for remove/insert TCP >> timeouts callbacks? > > > I am not sure what this formula means, but yes, per-CPU callout locks can > much more likely be congested. They are only per-CPU, not per-flow. It's not just that, but also TX versus RX ACK processing and further TX being done on different threads. -a From owner-freebsd-arch@FreeBSD.ORG Wed Feb 19 23:07:21 2014 Return-Path: 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 A26CCD34; Wed, 19 Feb 2014 23:07:21 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 4D1621E1E; Wed, 19 Feb 2014 23:07:21 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1WGGEZ-000Fl4-Uw; Thu, 20 Feb 2014 03:07:19 +0400 Date: Thu, 20 Feb 2014 03:07:19 +0400 From: Slawa Olhovchenkov To: Alexander Motin Subject: Re: [rfc] bind per-cpu timeout threads to each CPU Message-ID: <20140219230719.GM83358@zxy.spb.ru> References: <530508B7.7060102@FreeBSD.org> <53050D24.3020505@FreeBSD.org> <53051C71.3050705@FreeBSD.org> <20140219214428.GA53864@zxy.spb.ru> <53052B80.3010505@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53052B80.3010505@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: Adrian Chadd , freebsd-current , Jeffrey Faden , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 23:07:21 -0000 On Thu, Feb 20, 2014 at 12:09:04AM +0200, Alexander Motin wrote: > On 19.02.2014 23:44, Slawa Olhovchenkov wrote: > > On Wed, Feb 19, 2014 at 11:04:49PM +0200, Alexander Motin wrote: > > > >> On 19.02.2014 22:04, Adrian Chadd wrote: > >>> On 19 February 2014 11:59, Alexander Motin wrote: > >>> > >>>>> 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. > >>> > >>>> True, though it is also not obvious that putting second thread on CPU run > >>>> queue is better then executing it right now on another core. > >>> > >>> Well, it depends if you're trying to optimise for "run all runnable > >>> tasks as quickly as possible" or "run all runnable tasks in contexts > >>> that minimise lock contention." > >>> > >>> The former sounds great as long as there's no real lock contention > >>> going on. But as you add more chances for contention (something like > >>> "100,000 concurrent TCP flows") then you may end up having your TCP > >>> timer firing stuff interfere with more TXing or RXing on the same > >>> connection. > >> > >> 100K TCP flows probably means 100K locks. That means that chance of lock > >> collision on each of them is effectively zero. More realistic it could > > > > What about 100K/N_cpu*PPS timer's queue locks for remove/insert TCP > > timeouts callbacks? > > I am not sure what this formula means, but yes, per-CPU callout locks > can much more likely be congested. They are only per-CPU, not per-flow. 100K TCP flows distributed between CPU (100K/N_cpu). every TCP flow several times per seconds touch his callout (*PPS) From owner-freebsd-arch@FreeBSD.ORG Thu Feb 20 19:17:38 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0424DC1A; Thu, 20 Feb 2014 19:17:38 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CBCD714C7; Thu, 20 Feb 2014 19:17:37 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id DBF12B9D0; Thu, 20 Feb 2014 14:17:36 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org, "freebsd-arch@freebsd.org" Subject: Re: [rfc] bind per-cpu timeout threads to each CPU Date: Thu, 20 Feb 2014 14:17:34 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <530508B7.7060102@FreeBSD.org> <201402191602.54465.jhb@freebsd.org> In-Reply-To: <201402191602.54465.jhb@freebsd.org> MIME-Version: 1.0 Message-Id: <201402201417.34148.jhb@freebsd.org> Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 20 Feb 2014 14:17:37 -0500 (EST) Cc: Adrian Chadd , Alexander Motin X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 19:17:38 -0000 On Wednesday, February 19, 2014 4:02:54 pm John Baldwin wrote: > On Wednesday, February 19, 2014 3:04:51 pm Adrian Chadd wrote: > > On 19 February 2014 11:59, Alexander Motin wrote: > > > > >> 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. > > > > > True, though it is also not obvious that putting second thread on CPU run > > > queue is better then executing it right now on another core. > > > > Well, it depends if you're trying to optimise for "run all runnable > > tasks as quickly as possible" or "run all runnable tasks in contexts > > that minimise lock contention." > > > > The former sounds great as long as there's no real lock contention > > going on. But as you add more chances for contention (something like > > "100,000 concurrent TCP flows") then you may end up having your TCP > > timer firing stuff interfere with more TXing or RXing on the same > > connection. > > > > Chasing this stuff down is a pain, because it only really shows up > > when you're doing lots of concurrency. > > > > I'm happy to make this a boot-time option and leave it off for the > > time being. How's that? > > I think having it be a tunable would be good. OTOH, I could also > see another option which would be to pin all clock threads except > for the "default" one by default and only have the option control > whether or not the default thread is pinned to CPU 0 as callers > who use callout_on() are explicitly asking to run the callout on a > specific CPU. (A further variant of this would be to divorce cpu0's swi from the catch-all softclock and let the catch-all softclock float, but bind all the per-cpu swis) -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Thu Feb 20 21:48:07 2014 Return-Path: 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 8991E49A; Thu, 20 Feb 2014 21:48:07 +0000 (UTC) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0F3371470; Thu, 20 Feb 2014 21:48:06 +0000 (UTC) Received: by mail-qc0-f172.google.com with SMTP id w7so2077813qcr.3 for ; Thu, 20 Feb 2014 13:48:06 -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=4GJN0//Tf5Bsda8spC3fhecqJ4H69Oe1dPLf5ZdVP64=; b=Rhmhe5vI3V7pYkm16TajmVoJ9+8UPPBP4RR22ZT15MWKFkDEVPn5ZQxdxMn73aErjz TAfMrWt4MoaBo434h0+WpLgIq6e6TI44MpITOjaUCIIB7zmOp5ggIoFdk28tdBqk76JR w3LHPoFMkDDEq+f6hGVKn7E9xtsz/MqnINTAa7iJm99r9DVxLjiDhOBEUgs8C82SEsxR o7A+d4S2jFPyTSHfLRzQG5wBapJWVjsTE6hnfuyUMf4R/FWM9YYv9kvXc5osdHLDgvqi X5TI4OPo+hO1873TXWrqqfeuvsg5govqlPVy/qwx/P8yRDbaGYj/8XVJx8lwYxg0SfR7 K+Pw== MIME-Version: 1.0 X-Received: by 10.140.42.54 with SMTP id b51mr4580773qga.87.1392932886244; Thu, 20 Feb 2014 13:48:06 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.16.10 with HTTP; Thu, 20 Feb 2014 13:48:06 -0800 (PST) In-Reply-To: <201402201417.34148.jhb@freebsd.org> References: <530508B7.7060102@FreeBSD.org> <201402191602.54465.jhb@freebsd.org> <201402201417.34148.jhb@freebsd.org> Date: Thu, 20 Feb 2014 13:48:06 -0800 X-Google-Sender-Auth: vF-zuzXAj2DSvPJ2howbBaEpat4 Message-ID: Subject: Re: [rfc] bind per-cpu timeout threads to each CPU From: Adrian Chadd To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: Alexander Motin , freebsd-current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 21:48:07 -0000 On 20 February 2014 11:17, John Baldwin wrote: > (A further variant of this would be to divorce cpu0's swi from the > catch-all softclock and let the catch-all softclock float, but bind > all the per-cpu swis) I like this idea. If something (eg per-CPU TCP timers, if it's turned on) makes a very specific decision about the CPU then it should be fixed. Otherwise a lot of the underlying assumptions for things like RSS just aren't guaranteed to hold. It could also perhaps extend to some abstract pool of CPUs later, if we wanted to do things like one flowing swi per socket or whatnot when we start booting on 1024 core boxes... -a From owner-freebsd-arch@FreeBSD.ORG Fri Feb 21 12:05:53 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 517703A7; Fri, 21 Feb 2014 12:05:53 +0000 (UTC) Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F0E8B1532; Fri, 21 Feb 2014 12:05:52 +0000 (UTC) Received: by mail-ve0-f172.google.com with SMTP id jz11so1284668veb.31 for ; Fri, 21 Feb 2014 04:05:52 -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=DueIrPFTPvyiV3QkRdgFSdMZJI3aPCdfJBoovvgsK1U=; b=d8Wt/8mwL7UC61i0R/87dy4bvnCQ1uBFOxf32TytHNdQJ976U9/CHRww9Ki+ke3AXk rGILWOqcas8kl3flQnTfP7/2ilW1gGUINo/03sjXzxSxMstimLa0xN/lDrHitwpRFa8F vDqQfM4tk6Qa085gfeeCIHZHDYOWTUlbIKZI5usnomzLA32mTq6TfvZltc3NIb4l4NuT IuC2oHxdtSg4zXB7qj879fSN2eCr7TuLliNcjBZZ/SlFj9y6sjwpV7tWbiTJ3rx9bR/d Btmbg+9GwsNGDcdCIDBHVLqTL6SixdaDI8j6B1OGomdOb9SSqa/zoW6UFO/3fCVxWeFa LrTQ== MIME-Version: 1.0 X-Received: by 10.220.112.75 with SMTP id v11mr4533991vcp.74.1392984352088; Fri, 21 Feb 2014 04:05:52 -0800 (PST) Sender: edschouten@gmail.com Received: by 10.220.105.140 with HTTP; Fri, 21 Feb 2014 04:05:52 -0800 (PST) In-Reply-To: <5304A0CC.5000505@FreeBSD.org> References: <5304A0CC.5000505@FreeBSD.org> Date: Fri, 21 Feb 2014 13:05:52 +0100 X-Google-Sender-Auth: OQhDj2m-_xIuc0WJ1zE36G2vt0k Message-ID: Subject: Re: terminfo From: Ed Schouten To: Bryan Drewery Content-Type: text/plain; charset=UTF-8 Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 12:05:53 -0000 Hi Bryan, On 19 February 2014 13:17, Bryan Drewery wrote: > Why do we not use terminfo? Our termcap is quite aged and missing a lot > of modern terminals/clients. It is true that our termcap is quite aged, but the fact is, once you add entries for a certain terminal, there's little need to update it after that. ncurses itself is not really a moving target. What kind of modern terminals/clients are missing? > Using terminfo would allow us to use the already well maintained database from ncurses. Is it just a matter of someone doing the work or are there other reasons? It's just a matter of someone doing the work. It would be nice if we ever made this change. On the other hand, I might have a radical point of view here: maybe we could consider taking the approach of sticking to termcap and installing /etc/termcap.small as the system's default termcap. Or maybe patch up our termcap routines to just hardcode the sequences. I won't deny that termcap was really useful at one point in time, but let's be honest: the variety of terminals out there has massively dropped over time. Terminal emulation has become a solved problem. As of FreeBSD 9, syscons supports all the sequences described in xterm-256color, though it isn't able to print more than 8 colours, which is why we use TERM=xterm. Tools like screen, tmux, etc., they use a different TERM type, but this is mainly used to detect whether the process is running inside of screen or tmux. It does not strongly affect the kinds of sequences that are being emitted. They work perfectly fine if you just set TERM to xterm or xterm-256color. I suspect the following logic would be sufficient for at least 99.5% of our users: if $TERM contains 256 use xterm-256color else use xterm It's a shame I am so short on time nowadays, but I think it would make so much sense to just come up with some kind of document that standardizes the intersection of the features supported by most common terminal emulators and get it rubber stamped by the maintainers of various terminal emulators. If it turns out some kind of terminal emulator does something in a non-standard way, we can just slap this document in the author's face. That would not only benefit FreeBSD, but also most of the other flavours of UNIX. $TERM should die. -- Ed Schouten From owner-freebsd-arch@FreeBSD.ORG Fri Feb 21 15:46:33 2014 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B55EBC1F; Fri, 21 Feb 2014 15:46:33 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 880691C5B; Fri, 21 Feb 2014 15:46:33 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WGsJ6-000NuX-9Q; Fri, 21 Feb 2014 15:46:32 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s1LFkTQW032918; Fri, 21 Feb 2014 08:46:29 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19tW8dfkntqcITRp+y8T7d6 Subject: Re: terminfo From: Ian Lepore To: Ed Schouten In-Reply-To: References: <5304A0CC.5000505@FreeBSD.org> Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Feb 2014 08:46:29 -0700 Message-ID: <1392997589.1145.91.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org, Bryan Drewery X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 15:46:33 -0000 On Fri, 2014-02-21 at 13:05 +0100, Ed Schouten wrote: > Hi Bryan, > > On 19 February 2014 13:17, Bryan Drewery wrote: > > Why do we not use terminfo? Our termcap is quite aged and missing a lot > > of modern terminals/clients. > > It is true that our termcap is quite aged, but the fact is, once you > add entries for a certain terminal, there's little need to update it > after that. ncurses itself is not really a moving target. What kind of > modern terminals/clients are missing? > > > Using terminfo would allow us to use the already well maintained database from ncurses. Is it just a matter of someone doing the work or are there other reasons? > > It's just a matter of someone doing the work. It would be nice if we > ever made this change. > > On the other hand, I might have a radical point of view here: maybe we > could consider taking the approach of sticking to termcap and > installing /etc/termcap.small as the system's default termcap. Or > maybe patch up our termcap routines to just hardcode the sequences. > > I won't deny that termcap was really useful at one point in time, but > let's be honest: the variety of terminals out there has massively > dropped over time. Terminal emulation has become a solved problem. As > of FreeBSD 9, syscons supports all the sequences described in > xterm-256color, though it isn't able to print more than 8 colours, > which is why we use TERM=xterm. Tools like screen, tmux, etc., they > use a different TERM type, but this is mainly used to detect whether > the process is running inside of screen or tmux. It does not strongly > affect the kinds of sequences that are being emitted. They work > perfectly fine if you just set TERM to xterm or xterm-256color. > > I suspect the following logic would be sufficient for at least 99.5% > of our users: > > if $TERM contains 256 > use xterm-256color > else > use xterm > > It's a shame I am so short on time nowadays, but I think it would make > so much sense to just come up with some kind of document that > standardizes the intersection of the features supported by most common > terminal emulators and get it rubber stamped by the maintainers of > various terminal emulators. If it turns out some kind of terminal > emulator does something in a non-standard way, we can just slap this > document in the author's face. That would not only benefit FreeBSD, > but also most of the other flavours of UNIX. > > $TERM should die. > All of that seems to assume that every terminal actually being used in the world today is either xterm or something that emulates it. Try using vi on a serial console on an embedded ARM board and you'll get a quick frustrating lesson in how not-xterm a serial console is. I've yet to find a combo of serial comms program and TERM setting that actually works well and lets you edit a file with vi. -- Ian From owner-freebsd-arch@FreeBSD.ORG Fri Feb 21 18:15:46 2014 Return-Path: Delivered-To: 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 ADD835B3; Fri, 21 Feb 2014 18:15:46 +0000 (UTC) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 6C4A31C4E; Fri, 21 Feb 2014 18:15:46 +0000 (UTC) Received: from c122-106-144-87.carlnfd1.nsw.optusnet.com.au (c122-106-144-87.carlnfd1.nsw.optusnet.com.au [122.106.144.87]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id 1E962420D09; Sat, 22 Feb 2014 05:15:37 +1100 (EST) Date: Sat, 22 Feb 2014 05:15:06 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Ian Lepore Subject: Re: terminfo In-Reply-To: <1392997589.1145.91.camel@revolution.hippie.lan> Message-ID: <20140222030504.D3166@besplex.bde.org> References: <5304A0CC.5000505@FreeBSD.org> <1392997589.1145.91.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=HZAtEE08 c=1 sm=1 tr=0 a=p/w0leo876FR0WNmYI1KeA==:117 a=PO7r1zJSAAAA:8 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=IIIIMO1WzoMA:10 a=6I5d2MoRAAAA:8 a=ScsGqTL87VO4oIQuntwA:9 a=CjuIK1q_8ugA:10 a=SV7veod9ZcQA:10 Cc: Ed Schouten , Bryan Drewery , arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 18:15:46 -0000 On Fri, 21 Feb 2014, Ian Lepore wrote: > On Fri, 2014-02-21 at 13:05 +0100, Ed Schouten wrote: >> Hi Bryan, >> >> On 19 February 2014 13:17, Bryan Drewery wrote: >>> Why do we not use terminfo? Our termcap is quite aged and missing a lot >>> of modern terminals/clients. Why do we not use Windows? :-) >> It is true that our termcap is quite aged, but the fact is, once you >> add entries for a certain terminal, there's little need to update it >> after that. ncurses itself is not really a moving target. What kind of >> modern terminals/clients are missing? I tend to agree. I used to have several special termcap entries in .profile or .termcap because the system termcap was unreliable. Now after using mainly syscons for 20+ years, I have only 1 special termcap entry (a prefix to cons25) in .profile (to partly recover from breakage of some syscons escape sequences). >> ... >> I won't deny that termcap was really useful at one point in time, but >> let's be honest: the variety of terminals out there has massively >> dropped over time. Terminal emulation has become a solved problem. As >> of FreeBSD 9, syscons supports all the sequences described in >> xterm-256color, though it isn't able to print more than 8 colours, >> which is why we use TERM=xterm. Tools like screen, tmux, etc., they >> >> I suspect the following logic would be sufficient for at least 99.5% >> of our users: >> >> if $TERM contains 256 >> use xterm-256color >> else >> use xterm >> ... >> $TERM should die. > > All of that seems to assume that every terminal actually being used in > the world today is either xterm or something that emulates it. Try > using vi on a serial console on an embedded ARM board and you'll get a > quick frustrating lesson in how not-xterm a serial console is. I've yet > to find a combo of serial comms program and TERM setting that actually > works well and lets you edit a file with vi. What display device is the ARM board connected to that causes a problem? I use an intentionally simple terminal program that does no translation, and haven't noticed many problems. Even tip/cu should work similarly. TERM/TERMCAP/.termcap are just the host's values for non-serial terminal activity. These must be copied to all targets. This only works for hosts and targets that are Unix-like OSes which support TERM/TERMCAP/.termcap of course. The display hardware and the software that controls it is on the PC so its escape sequences can be anything I want. Bruce From owner-freebsd-arch@FreeBSD.ORG Fri Feb 21 18:35:23 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ABA9BEA0; Fri, 21 Feb 2014 18:35:23 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6B2421DE6; Fri, 21 Feb 2014 18:35:23 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s1LIZC8s044675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Feb 2014 10:35:12 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s1LIZCcc044674; Fri, 21 Feb 2014 10:35:12 -0800 (PST) (envelope-from jmg) Date: Fri, 21 Feb 2014 10:35:12 -0800 From: John-Mark Gurney To: Ian Lepore Subject: Re: terminfo Message-ID: <20140221183512.GP34851@funkthat.com> Mail-Followup-To: Ian Lepore , Ed Schouten , arch@freebsd.org, Bryan Drewery References: <5304A0CC.5000505@FreeBSD.org> <1392997589.1145.91.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1392997589.1145.91.camel@revolution.hippie.lan> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 21 Feb 2014 10:35:12 -0800 (PST) Cc: Ed Schouten , Bryan Drewery , arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 18:35:23 -0000 Ian Lepore wrote this message on Fri, Feb 21, 2014 at 08:46 -0700: > On Fri, 2014-02-21 at 13:05 +0100, Ed Schouten wrote: > > It's a shame I am so short on time nowadays, but I think it would make > > so much sense to just come up with some kind of document that > > standardizes the intersection of the features supported by most common > > terminal emulators and get it rubber stamped by the maintainers of > > various terminal emulators. If it turns out some kind of terminal > > emulator does something in a non-standard way, we can just slap this > > document in the author's face. That would not only benefit FreeBSD, > > but also most of the other flavours of UNIX. > > > > $TERM should die. > > > > All of that seems to assume that every terminal actually being used in > the world today is either xterm or something that emulates it. Try > using vi on a serial console on an embedded ARM board and you'll get a > quick frustrating lesson in how not-xterm a serial console is. I've yet > to find a combo of serial comms program and TERM setting that actually > works well and lets you edit a file with vi. Have you used screen? screen /dev/ttyXXX 9600 It's pretty much the only serial console program I use because I use screen, and remebering how to use tip/cu w/ a new random USB serial device is anoying... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Fri Feb 21 18:44:32 2014 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CEA3553C; Fri, 21 Feb 2014 18:44:32 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9C3AD1FAF; Fri, 21 Feb 2014 18:44:32 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WGv5L-0001S6-51; Fri, 21 Feb 2014 18:44:31 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s1LIiSkR033148; Fri, 21 Feb 2014 11:44:28 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX180a2knOGvCsBRTW/Yx0o5M Subject: Re: terminfo From: Ian Lepore To: John-Mark Gurney In-Reply-To: <20140221183512.GP34851@funkthat.com> References: <5304A0CC.5000505@FreeBSD.org> <1392997589.1145.91.camel@revolution.hippie.lan> <20140221183512.GP34851@funkthat.com> Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Feb 2014 11:44:27 -0700 Message-ID: <1393008267.1145.117.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org, Ed Schouten , Bryan Drewery X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 18:44:32 -0000 On Fri, 2014-02-21 at 10:35 -0800, John-Mark Gurney wrote: > Ian Lepore wrote this message on Fri, Feb 21, 2014 at 08:46 -0700: > > On Fri, 2014-02-21 at 13:05 +0100, Ed Schouten wrote: > > > It's a shame I am so short on time nowadays, but I think it would make > > > so much sense to just come up with some kind of document that > > > standardizes the intersection of the features supported by most common > > > terminal emulators and get it rubber stamped by the maintainers of > > > various terminal emulators. If it turns out some kind of terminal > > > emulator does something in a non-standard way, we can just slap this > > > document in the author's face. That would not only benefit FreeBSD, > > > but also most of the other flavours of UNIX. > > > > > > $TERM should die. > > > > > > > All of that seems to assume that every terminal actually being used in > > the world today is either xterm or something that emulates it. Try > > using vi on a serial console on an embedded ARM board and you'll get a > > quick frustrating lesson in how not-xterm a serial console is. I've yet > > to find a combo of serial comms program and TERM setting that actually > > works well and lets you edit a file with vi. > > Have you used screen? > > screen /dev/ttyXXX 9600 > > It's pretty much the only serial console program I use because I use > screen, and remebering how to use tip/cu w/ a new random USB serial > device is anoying... > screen is what I finally settled on as the least-horrible option, but it barely works for anything except scrolling text and typing command lines. Anything fullscreen works a bit and fails a bit in different ways with different TERM= values. I've never used cu, forgot it even exists, but several people have mentioned it, so I'll give it a try. I tend to shy away from 1980s-vintage tools because they're so... 1980s. (tip, for example, is just an abomination). -- Ian From owner-freebsd-arch@FreeBSD.ORG Fri Feb 21 19:14:23 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 998D1424 for ; Fri, 21 Feb 2014 19:14:23 +0000 (UTC) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 50E0A1286 for ; Fri, 21 Feb 2014 19:14:23 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id id10so3648995vcb.41 for ; Fri, 21 Feb 2014 11:14:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Evp/jmYgXIBtNK4+qtn5d8c+HdujdV/nBiyCYihvUrc=; b=Wr2l8iUzmdHqR3HC/FvX20ChBdKIB0DnJynnWC5EK9oq3b2b34JIxOmWOhW9nxbKIo 6llOpq7c5wIkTiBDrBrwGWyW4qXkdfJKOk7XpW4ZK1G0K3WYv+lws3Zyi7W8A5BfkXtA nVMbNiUkZaZx14Gx4KOnWIqmNI+G6uaJRLVO4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Evp/jmYgXIBtNK4+qtn5d8c+HdujdV/nBiyCYihvUrc=; b=I85GF7AFjxAHB7rzXtbV26sv8Y+nAlcuC83qumKSaCoPeCeoMWcgSndNqWLM9+9mYg KxUgnUZdYNxWvovfQxkccuk1Et5Jmrt1rSoA/+nOdMEKlNyN44t8H0YjZ6Dyqriy2nj3 CWfoHNKlKvZtLlKFR7Lqy67ye+ko5HeYzYQfbQpQdHey/3RT11FhPii1Czjw/NxY9c8j sxOeVz7j0UToAJuCMeDPOcHhEaxdNejCcUhbs6P1rXz1/54YRop1ijbTJCVx8AFxrGMs DmPqla2jOwd4A0Z8XKJIqi2BKQjhkHr4WLoZSTwUz8tY6NEGQRRcBy6cMkLezBTGihPe hAXA== X-Gm-Message-State: ALoCoQlngWHwmrL8dsdnV7BLwlhHrAZHcDdjSblt53Y4gSag7WaQzSeLrZkVBmuBidOCdpaPxr+e MIME-Version: 1.0 X-Received: by 10.220.47.10 with SMTP id l10mr5920368vcf.56.1393010062368; Fri, 21 Feb 2014 11:14:22 -0800 (PST) Received: by 10.220.30.69 with HTTP; Fri, 21 Feb 2014 11:14:22 -0800 (PST) In-Reply-To: <5304A0CC.5000505@FreeBSD.org> References: <5304A0CC.5000505@FreeBSD.org> Date: Fri, 21 Feb 2014 11:14:22 -0800 Message-ID: Subject: Re: terminfo From: Peter Wemm To: Bryan Drewery Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 19:14:23 -0000 On Wed, Feb 19, 2014 at 4:17 AM, Bryan Drewery wrote: > Why do we not use terminfo? Our termcap is quite aged and missing a lot > of modern terminals/clients. Using terminfo would allow us to use the > already well maintained database from ncurses. > > Is it just a matter of someone doing the work or are there other reasons? > > -- > Regards, > Bryan Drewery > There are historical reasons. As the person who imported the current setup I have some insight into that. One issue was because cons25 / syscons was evolving. That's no longer the case. Because things were in flux, people accumulated their own rules. Another was that termcap was the source of truth on 4.x BSD systems, but we could translate into terminfo dynamically for things that needed it. At the time, the reverse wasn't adequate - the ncurses provided terminfo wasn't rich enough to express everything we had in termcap so we couldn't do a lossless conversion of our home grown termcap rules into terminfo and get everything back through the emulator. There were personal preferences as well - the ncurses terminfo at the time was sysv-style and was a fixed binary format and non-extensible while termcap was flexible and freely extendable. HOWEVER, if I were to do it today, I would be inclined to use netbsd's libtinfo and cdb modules and switch to terminfo as the source of truth. It is my understanding that netbsd's libtinfo "compiles" into a .cdb format file and gives us the same flexibility that we have with termcap/termcap.db without the non-extensible sysv binary format lock-in. Then have ncurses use it instead, like netbsd does. We get to import the ncurses sourced terminfo database and port over our tweaks/extensions as needed. As has been pointed out in other followups.. the ones that really matter are xterm/xterm-color/vt100/cons25. And less so on including cons25 in that as syscons can speak xterm now and the others are xterm only. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV Yes, I know, gmail sucks now. If you see this then I forgot. Habits are hard to break. From owner-freebsd-arch@FreeBSD.ORG Fri Feb 21 19:14:40 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1BDFF4DB for ; Fri, 21 Feb 2014 19:14:40 +0000 (UTC) Received: from mail-pb0-f43.google.com (mail-pb0-f43.google.com [209.85.160.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E0FBB128D for ; Fri, 21 Feb 2014 19:14:39 +0000 (UTC) Received: by mail-pb0-f43.google.com with SMTP id ma3so1206726pbc.30 for ; Fri, 21 Feb 2014 11:14:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=Gko0uBJCnRlEFu41BCoMKrehMYS04gbt4roy7IP26Rw=; b=SlREFHgS79QaBLJ3erHXGmQIusv4oDb2Fq5fmgVWBE6KUwBt2uwhzdD1dCGpEOXI2f AJZzdmFoErZJU/k4m7vzA8ss+O6DkvR3c5vaRQMnSraBFscJ6W82C7/6+FsVZmU16a2G rPw2xlmOQGWKgZ87PnriY3KP/AkpTPi73d0W4vPIcVqnmZOnkE1mGnQ3qbDGLhaXADrO CecoNqV7SWdkaf7Aw2E1C2XcI0JTo0O9NMt/njNBASbn61b6+OUwn9yeUICLyGBHft3S hS8nlLUwDIHeKe3ggSHyqOoC+xTM8sbhCuoStygjfa3mTBR3zyH1DBc+vT00we8PMl+O C1Rw== X-Gm-Message-State: ALoCoQnV5xQI/iON1DBSetTuF3P09QQo6qY6MgxtjViFahl2WzkeOFKNLX+j3ftJD4RAVrn1DSEj X-Received: by 10.69.0.39 with SMTP id av7mr11024102pbd.4.1393010078988; Fri, 21 Feb 2014 11:14:38 -0800 (PST) Received: from macmini.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id cz3sm23907917pbc.9.2014.02.21.11.14.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Feb 2014 11:14:37 -0800 (PST) Subject: Re: terminfo Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1392997589.1145.91.camel@revolution.hippie.lan> Date: Fri, 21 Feb 2014 12:14:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5304A0CC.5000505@FreeBSD.org> <1392997589.1145.91.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1085) Cc: Ed Schouten , Bryan Drewery , arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 19:14:40 -0000 On Feb 21, 2014, at 8:46 AM, Ian Lepore wrote: > On Fri, 2014-02-21 at 13:05 +0100, Ed Schouten wrote: >> Hi Bryan, >>=20 >> On 19 February 2014 13:17, Bryan Drewery = wrote: >>> Why do we not use terminfo? Our termcap is quite aged and missing a = lot >>> of modern terminals/clients. >>=20 >> It is true that our termcap is quite aged, but the fact is, once you >> add entries for a certain terminal, there's little need to update it >> after that. ncurses itself is not really a moving target. What kind = of >> modern terminals/clients are missing? >>=20 >>> Using terminfo would allow us to use the already well maintained = database from ncurses. Is it just a matter of someone doing the work or = are there other reasons? >>=20 >> It's just a matter of someone doing the work. It would be nice if we >> ever made this change. >>=20 >> On the other hand, I might have a radical point of view here: maybe = we >> could consider taking the approach of sticking to termcap and >> installing /etc/termcap.small as the system's default termcap. Or >> maybe patch up our termcap routines to just hardcode the sequences. >>=20 >> I won't deny that termcap was really useful at one point in time, but >> let's be honest: the variety of terminals out there has massively >> dropped over time. Terminal emulation has become a solved problem. As >> of FreeBSD 9, syscons supports all the sequences described in >> xterm-256color, though it isn't able to print more than 8 colours, >> which is why we use TERM=3Dxterm. Tools like screen, tmux, etc., they >> use a different TERM type, but this is mainly used to detect whether >> the process is running inside of screen or tmux. It does not strongly >> affect the kinds of sequences that are being emitted. They work >> perfectly fine if you just set TERM to xterm or xterm-256color. >>=20 >> I suspect the following logic would be sufficient for at least 99.5% >> of our users: >>=20 >> if $TERM contains 256 >> use xterm-256color >> else >> use xterm >>=20 >> It's a shame I am so short on time nowadays, but I think it would = make >> so much sense to just come up with some kind of document that >> standardizes the intersection of the features supported by most = common >> terminal emulators and get it rubber stamped by the maintainers of >> various terminal emulators. If it turns out some kind of terminal >> emulator does something in a non-standard way, we can just slap this >> document in the author's face. That would not only benefit FreeBSD, >> but also most of the other flavours of UNIX. >>=20 >> $TERM should die. >>=20 >=20 > All of that seems to assume that every terminal actually being used in > the world today is either xterm or something that emulates it. Try > using vi on a serial console on an embedded ARM board and you'll get a > quick frustrating lesson in how not-xterm a serial console is. I've = yet > to find a combo of serial comms program and TERM setting that actually > works well and lets you edit a file with vi. I'd go so far as to say that no such subset actually exists. There's = nothing wrong with TERM, and it has abstracted away all the differences = for many, many years. I've had good luck with TERM=3Dvt100 in those situations, but I use tip = and apart from eating ^P it does a good job of being transparent = enough... Let's not kill $TERM... There seems to be no benefit, and lots of pain. Warner= From owner-freebsd-arch@FreeBSD.ORG Fri Feb 21 20:51:11 2014 Return-Path: Delivered-To: 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 C325F200; Fri, 21 Feb 2014 20:51:11 +0000 (UTC) Received: from mail106.syd.optusnet.com.au (mail106.syd.optusnet.com.au [211.29.132.42]) by mx1.freebsd.org (Postfix) with ESMTP id 836121B1C; Fri, 21 Feb 2014 20:51:11 +0000 (UTC) Received: from c122-106-144-87.carlnfd1.nsw.optusnet.com.au (c122-106-144-87.carlnfd1.nsw.optusnet.com.au [122.106.144.87]) by mail106.syd.optusnet.com.au (Postfix) with ESMTPS id A6A1E3C0DCA; Sat, 22 Feb 2014 07:26:23 +1100 (EST) Date: Sat, 22 Feb 2014 07:26:22 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Peter Wemm Subject: Re: terminfo In-Reply-To: Message-ID: <20140222063006.T4103@besplex.bde.org> References: <5304A0CC.5000505@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=bpB1Wiqi c=1 sm=1 tr=0 a=p/w0leo876FR0WNmYI1KeA==:117 a=PO7r1zJSAAAA:8 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=IIIIMO1WzoMA:10 a=6I5d2MoRAAAA:8 a=DarwwxSEiXKCcQh9X7IA:9 a=CjuIK1q_8ugA:10 a=SV7veod9ZcQA:10 Cc: FreeBSD Arch , Bryan Drewery X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 20:51:11 -0000 On Fri, 21 Feb 2014, Peter Wemm wrote: > On Wed, Feb 19, 2014 at 4:17 AM, Bryan Drewery wrote: >> Why do we not use terminfo? Our termcap is quite aged and missing a lot >> of modern terminals/clients. Using terminfo would allow us to use the >> already well maintained database from ncurses. >> >> Is it just a matter of someone doing the work or are there other reasons? > > There are historical reasons. As the person who imported the current > setup I have some insight into that. > > One issue was because cons25 / syscons was evolving. That's no longer > the case. Because things were in flux, people accumulated their own > rules. Another was that termcap was the source of truth on 4.x BSD > systems, but we could translate into terminfo dynamically for things > that needed it. At the time, the reverse wasn't adequate - the > ncurses provided terminfo wasn't rich enough to express everything we > had in termcap so we couldn't do a lossless conversion of our home > grown termcap rules into terminfo and get everything back through the > emulator. There were personal preferences as well - the ncurses > terminfo at the time was sysv-style and was a fixed binary format and > non-extensible while termcap was flexible and freely extendable. My preference is to have not stopped using 4.4BSD termcap and curses, except to simplify it a bit. NetBSD was still using 4.4-based libterm and libcurses in 2005, except to expand them a lot. > HOWEVER, if I were to do it today, I would be inclined to use netbsd's > libtinfo and cdb modules and switch to terminfo as the source of > truth. It is my understanding that netbsd's libtinfo "compiles" into > a .cdb format file and gives us the same flexibility that we have with > termcap/termcap.db without the non-extensible sysv binary format > lock-in. Then have ncurses use it instead, like netbsd does. We get > to import the ncurses sourced terminfo database and port over our > tweaks/extensions as needed. Ugh, more binary mistakes. This reminds me that I wanted to remove the .db form in ~1995. Even in 1995, you could read and parse the whole 200K termcap.src file in not very long compared with the startup time of an interactive application large enough to use termcap. But it is even better to not have a big termcap file full of support for hardware terminals that haven't been produced since 1985. This is most easily implemented (incorrectly) by copying a few fixed entries to /etc/termcap at install time. I think users have always been able to get a faster startup by copying the one entry that they use (or currently use) to ther TERMCAP environment variable or their .termcap (hopefully the implementation doesn't look elsewhere then). Bruce From owner-freebsd-arch@FreeBSD.ORG Fri Feb 21 21:27:36 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D3233CE7; Fri, 21 Feb 2014 21:27:36 +0000 (UTC) Received: from mail110.syd.optusnet.com.au (mail110.syd.optusnet.com.au [211.29.132.97]) by mx1.freebsd.org (Postfix) with ESMTP id 8F1DD1DF3; Fri, 21 Feb 2014 21:27:36 +0000 (UTC) Received: from c122-106-144-87.carlnfd1.nsw.optusnet.com.au (c122-106-144-87.carlnfd1.nsw.optusnet.com.au [122.106.144.87]) by mail110.syd.optusnet.com.au (Postfix) with ESMTPS id 6DF4A780B78; Sat, 22 Feb 2014 07:57:39 +1100 (EST) Date: Sat, 22 Feb 2014 07:57:37 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Ian Lepore Subject: Re: terminfo In-Reply-To: <1393008267.1145.117.camel@revolution.hippie.lan> Message-ID: <20140222072702.X4354@besplex.bde.org> References: <5304A0CC.5000505@FreeBSD.org> <1392997589.1145.91.camel@revolution.hippie.lan> <20140221183512.GP34851@funkthat.com> <1393008267.1145.117.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=bpB1Wiqi c=1 sm=1 tr=0 a=p/w0leo876FR0WNmYI1KeA==:117 a=PO7r1zJSAAAA:8 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=IIIIMO1WzoMA:10 a=Q_5l-ThESSo6xtWxTxIA:9 a=ujLsXuiRjwK7CVcR:21 a=rQXDIDA40SY-SDBI:21 a=CjuIK1q_8ugA:10 Cc: arch@freebsd.org, John-Mark Gurney , Bryan Drewery , Ed Schouten X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 21:27:36 -0000 On Fri, 21 Feb 2014, Ian Lepore wrote: > On Fri, 2014-02-21 at 10:35 -0800, John-Mark Gurney wrote: >> Ian Lepore wrote this message on Fri, Feb 21, 2014 at 08:46 -0700: >>> >>> All of that seems to assume that every terminal actually being used in >>> the world today is either xterm or something that emulates it. Try >>> using vi on a serial console on an embedded ARM board and you'll get a >>> quick frustrating lesson in how not-xterm a serial console is. I've yet >>> to find a combo of serial comms program and TERM setting that actually >>> works well and lets you edit a file with vi. >> >> Have you used screen? >> >> screen /dev/ttyXXX 9600 >> >> It's pretty much the only serial console program I use because I use >> screen, and remebering how to use tip/cu w/ a new random USB serial >> device is anoying... > > screen is what I finally settled on as the least-horrible option, but it > barely works for anything except scrolling text and typing command > lines. Anything fullscreen works a bit and fails a bit in different > ways with different TERM= values. I used it a bit over 20 years (just for local shells) but was happy to rmrf it. IIRC, it used curses, at least back them, and had slow screen refresh and/or scrolling and display artifacts. (I am sensitive to these and wasn't happy until the average scrolling speed reached a few hundred thousand lines per second (this happens partly virtually in syscons)). Virtual ttys work better for text displays and xterms work better for bitmapped displays. > I've never used cu, forgot it even exists, but several people have > mentioned it, so I'll give it a try. I tend to shy away from > 1980s-vintage tools because they're so... 1980s. (tip, for example, is > just an abomination). tip is too bloated for me, though I sometimes miss its ability to send a line break. I don't know what you are doing to for TERM to not just work. I can barely see the difference between a serial tty login and an ssh login. Serial logins at only 115200 bps are a bit slow, but so are intercontinental ssh's to freefall. Bruce From owner-freebsd-arch@FreeBSD.ORG Sat Feb 22 07:31:26 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 735D37AA; Sat, 22 Feb 2014 07:31:26 +0000 (UTC) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 040681B0C; Sat, 22 Feb 2014 07:31:25 +0000 (UTC) Received: by mail-vc0-f174.google.com with SMTP id im17so4199917vcb.33 for ; Fri, 21 Feb 2014 23:31:25 -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=CkBv4tn5OINcmvk3FwJIzY1r5zDIUPteLL5YWWBsnbw=; b=NI0sIlF434C8ciDa6o7b34mXfIwHHVUqpBQDqTKGP8Gy1OKETNVppYnCnHykWrd6jc sgXt2Xqgjz8JonHDyEhsuXyWvzi393AlW6B0PVqoX1YNShjo5cIt1t3ha9/KDTy4YJP7 ckl2YWS97igwoQlc7abIiSwDGW9pyqPEca36s9u+SayvFO/1labaU/CYHH1w8/ApEIiD 1HIQywj2ZaqbwEdRnptCfOPcHr/W+wkEfPaw30UMJWvQPP1+h5044uXwBr6FuKnfaFh5 RCOFfTQVk+acgRGnKbR5oHgc51xwYTf+MdRjqj/4Q1ky5n2ALR9b+1AUTf4rgFxjU1sY nkrg== MIME-Version: 1.0 X-Received: by 10.52.77.9 with SMTP id o9mr6069554vdw.82.1393054285142; Fri, 21 Feb 2014 23:31:25 -0800 (PST) Sender: edschouten@gmail.com Received: by 10.220.105.140 with HTTP; Fri, 21 Feb 2014 23:31:25 -0800 (PST) In-Reply-To: <1392997589.1145.91.camel@revolution.hippie.lan> References: <5304A0CC.5000505@FreeBSD.org> <1392997589.1145.91.camel@revolution.hippie.lan> Date: Sat, 22 Feb 2014 08:31:25 +0100 X-Google-Sender-Auth: 3KtVgBPzORnZRIJzcVSe4GoJIbc Message-ID: Subject: Re: terminfo From: Ed Schouten To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Cc: arch@freebsd.org, Bryan Drewery X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2014 07:31:26 -0000 On 21 February 2014 16:46, Ian Lepore wrote: > All of that seems to assume that every terminal actually being used in > the world today is either xterm or something that emulates it. Try > using vi on a serial console on an embedded ARM board and you'll get a > quick frustrating lesson in how not-xterm a serial console is. I've yet > to find a combo of serial comms program and TERM setting that actually > works well and lets you edit a file with vi. Which, in almost all cases, is problematic due to the fact that the other side is unaware of the window size of your terminal. If you use stty(1) to set that up right on the other side, it typically works pretty good from there on. -- Ed Schouten