From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <7aa20c07322147e6@orthanc.ca> References: <7aa20c07322147e6@orthanc.ca> From: hiro <23hiro@gmail.com> Date: Fri, 12 Oct 2018 00:28:10 +0200 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset="UTF-8" Subject: Re: [9fans] zero copy & 9p (was Re: PDP11 (Was: Re: what heavy negativity!) Topicbox-Message-UUID: ed219010-ead9-11e9-9d60-3106f5b1d025 i'm not saying you should measure a lot even. just trying to make you verify my point that this is not your bottleneck, just check if you hit a cpu limit already with that single processing stage (my guess was FFT). the reason why i think my guess is right is bec. of experience with the low bandwidth of SEQUENTIAL data you're claiming could create problems. in contrast i'm happy stallione at least brought up something more demanding earlier, like finding true limits during small block-size random access. On 10/11/18, Lyndon Nerenberg wrote: > Another case to ponder ... We're handling the incoming I/Q data > stream, but need to fan that out to many downstream consumers. If > we already read the data into a page, then flip it to the first > consumer, is there a benefit to adding a reference counter to that > read-only page and leaving the page live until the counter expires? > > Hiro clamours for benchmarks. I agree. Some basic searches I've > done don't show anyone trying this out with P9 (and publishing > their results). Anybody have hints/references to prior work? > > --lyndon > >