From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Wed, 10 Oct 2018 06:58:06 -0700 To: 9fans@9fans.net Message-ID: In-Reply-To: <1806122E-7160-403A-A2F0-027E5E77E31A@bitblocks.com> References: <1806122E-7160-403A-A2F0-027E5E77E31A@bitblocks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] PDP11 (Was: Re: what heavy negativity!) Topicbox-Message-UUID: eb2e74bc-ead9-11e9-9d60-3106f5b1d025 > > with meltdown/Spectre mitigations in place, I would like to see evidence that flip is faster than copy. > > If your system is well balanced, you should be able to > stream data as fast as memory allows[1]. In such a system > copying things N times will reduce throughput by similar > factor. It may be that plan9 underperforms so much this > doesn't matter normally. sure. but flipping page tables is also not free. there is a huge cost in processor stalls, etc. spectre and meltdown mitigations make this worse as each page flip has to be accompanied by a complete pipeline flush or other costly mitigation. (not that this was cheap to begin with) it's also not an object to move data as fast as possible. the object is to do work as fast as possible. > [1] See: https://code.kx.com/q/cloud/aws/benchmarking/ > A single q process can ingest data at 1.9GB/s from a > single drive. 16 can achieve 2.7GB/s, with theoretical > max being 2.8GB/s. with my same crappy un-optimized nvme driver, i was able to hit 2.5-2.6 GiB/s with two very crappy nvme drives. (are you're numbers really GB rather than GiB?) i am sure i could scale that lineraly. there's plenty of memory bandwidth left, but i haven't got any more nvme. :-) similarly coraid built an appliance that did copying (due to cache) and hit 1 million 4k iops. this was in 2011 or so. but, so what. all this proves is that with copying or without, we can ingest enough data for even the most hungry programs. unless you have data that shows otherwise. :-) - erik