Date: Tue, 4 Mar 2014 09:33:11 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: Justin Hibbits <jhibbits@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: newcons fb driver Message-ID: <20140304071445.Y3158@besplex.bde.org> In-Reply-To: <60475.1393876211@critter.freebsd.dk> References: <42130.1393829535@critter.freebsd.dk> <5314B2A2.3060100@pix.net> <CAHSQbTBTq6EKD_crn=rvbeUcAEBn7E%2B=U8wRHeqchazF1LhjwQ@mail.gmail.com> <60475.1393876211@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 3 Mar 2014, Poul-Henning Kamp wrote: > In message <CAHSQbTBTq6EKD_crn=3DrvbeUcAEBn7E+=3DU8wRHeqchazF1LhjwQ@mail.= gmail.com> > , Justin Hibbits writes: >> On Mon, Mar 3, 2014 at 8:49 AM, Kurt Lidl <lidl@pix.net> wrote: > >> All great knowledge, but really only answers half of what I'm looking >> for (always good to know potential pitfalls). Assuming a >> tunable/sysctl is added, what's the best way to optimize from my >> original post? Use a backing buffer (potentially with a tunable to >> not)? Or assume we don't support background images, and write the >> background color in the masked pixels? > > You should probably drop sos@ aka S=F8ren Schmidt an email, he did > syscons and has 10+ years experience in this stuff. > > One advantage of a backing buffer is that you can implement things > like the 1000 line scroll buffer syscons did etc, I personally use > that a lot to see dmesg output etc. Is newcons so much worse than syscons that it doesn't even have a backing buffer? Backing buffers are a fundamental part of virtual consoles. Only one virtual console at a time uses the frame buffer, and the output to the others is virtual. Output to the one using the frame buffer is not much different to output for others when they are switched to active. The output should be delayed as long as possible to give a refresh rate faster than anyone's eyes can notice. 100-200 Hz is adequate, but I try to make it thousands of times faster than that so that 100% of 1 CPU isn't needed for screen output. syscons in an old version of FreeBSD now gives me i/o speeds of 26MB/S to an active console and 29MB/S to an inactive console. In text mode of course. That is quite slow even for 10+ year old hardware that it was re-tested on (old tests gave approximately the frame buffer speed and I mostly stopped running them when frame buffers got fast enough for text). Except with 20+ year old hardware, the frame buffer speed makes little difference in this test. Graphics mode is harder to make acceptably fast. Why would newcons need to start supporting bytewise i/o now? Hardware was rarely broken enough to need it even in FreeBSD-1, and syscons has always been sloppy about it. i386 (but not amd64) has a bogus function bcopyb() for doing such i/o. This was used mainly by the 4+ (3+ too many) console drivers in 386BSD, FreeBSD-1 and/or FreeBSD-2.0. syscons never used it. In FreeBSD-4, it was used by pcvt. pcvt used it only for the character set initialization where speed is unimportant. Now bcopyb() still exists, but is never used. Another reason that bcopyb() is bogus is that i/o should be done using bus space. dev/fb still has many hacks to avoid using bus-space. Only ia64 is clean there. Other arches use massive ifdef tangles to do things wrong. Old versions of x86 used mostly bcopy() on frame buffers, but now use a home made 16-bit copying function. arm and mips still use bcopy() but misspell it memcpy(). Bruce From owner-freebsd-arch@FreeBSD.ORG Tue Mar 4 01:17:09 2014 Return-Path: <owner-freebsd-arch@FreeBSD.ORG> Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CCA3FD93; Tue, 4 Mar 2014 01:17:09 +0000 (UTC) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 790E6B36; Tue, 4 Mar 2014 01:17:09 +0000 (UTC) Received: by mail-qa0-f52.google.com with SMTP id m5so4256646qaj.39 for <multiple recipients>; Mon, 03 Mar 2014 17:17:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=/BSvHUXI/1mzcKfA02fxoe/7E4W8rPdRl519zAHMYvI=; b=VILdh2p3V1Tnetbgmee2b/7R2ceKK5LeZBFUsAYfaaTFB8Vb0r4bokQgMsc1XenZ0L SfAR+gqP+hk19O6awjdsAG3R9oLN4kUEMaShq4xYMEtStnn5sMEk9GmzQbqmkO0L2PoU DUFF4q2R0yXZp+j4zCvrTyY7V+8+LkFdR8RLrS+z0v/gUJcOtl3MLlJD0qiwFbf/bXbl PqaFLFMoTZXRJKW7uL34nxJIOhJ7CLkL25SHALGvrJRX3OQ6II2nnPdoKqVsTBqLt5Rt EloINpoVTN+SwBCtyBOrTw1gEq0NqFURX9n6ed3JgfTs1PKTgjUJGrDKzBVJMBl6W8+P AWOw== MIME-Version: 1.0 X-Received: by 10.140.42.138 with SMTP id c10mr26749023qga.24.1393895828549; Mon, 03 Mar 2014 17:17:08 -0800 (PST) Received: by 10.224.16.10 with HTTP; Mon, 3 Mar 2014 17:17:08 -0800 (PST) Date: Mon, 3 Mar 2014 17:17:08 -0800 Message-ID: <CAJ-VmomNsR5n8K7k+qcTAaAn0HiUcxmFVDxJUw8AD5ZyKHTn5w@mail.gmail.com> Subject: UDP transmit and no flowid From: Adrian Chadd <adrian.chadd@gmail.com> To: FreeBSD Net <freebsd-net@freebsd.org>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> 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 <freebsd-arch.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arch>, <mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch/>; List-Post: <mailto:freebsd-arch@freebsd.org> List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>, <mailto:freebsd-arch-request@freebsd.org?subject=subscribe> X-List-Received-Date: Tue, 04 Mar 2014 01:17:09 -0000 Hi, So something I was told about whilst investigating RSS at Netflix was that the UDP path doesn't actually get set by anything unless you're using flowtable. So, if one doesn't define flowtable, the transmit path congests quite heavily through one TX queue. I was about to do up a simple hack to do a toeplitz hash in the UDP send path before it gets bumped up to ip_output() - that way it can set the flowid correctly. The other option is to do a topelitz hash in ip_output() if m_flowid isn't set. The downside there is that we'd have to check whether it's actually a TCP, UDP, or IP flow before we assign it a flowid. In any case, this would likely decongest the transmit path quite a bit for UDP send. It's still not completely RSS-y (we would still need to line up transmit and receive paths to minimise lock contention) but it seems like a necessary first step in that direction. What do people think? I'll try this out in the next week or two once I've sorted out my employment situation and I can reserve some time on the netperf cluster. (before people ask "why udp?" - I'm kinda fed up with memcached performing much worse on freebsd than linux. Since fixing the UDP side of things requires a subset of the same work needed for TCP, I figure we should tackle UDP first.) Thanks, -adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140304071445.Y3158>