zero copy is also the source of the dreaded 'D' state.- Erik
Il giorno mar 9 ott 2018 alle ore 05:33 Lucio De Re
ha scritto:
>
> On 10/9/18, Bakul Shah wrote:
> >
> > One thing I have mused about is recasting plan9 as a
> > microkernel and pushing out a lot of its kernel code into user
> > mode code. It is already half way there -- it is basically a
> > m
I don't know which other ARM board you tried, but I have always found
terrible I/O performance of the Pi to be a bigger problem that the ARM
speed. The USB2 interface is really slow, and there arn't really many
other (documented) alternative options. The Ethernet goes through the same
slow USB int
I agree, if you have a choice avoid rpi by all costs.
Even if the software side of that other board was less pleasent at least it
worked with my mouse and keyboard!! :)
As I said I was looking at 2Mbit/s stuff, which is nothing, even over USB.
But my point is that even though this number is low, t
On Tue, Oct 9, 2018, at 11:22 PM, Digby R.S. Tarvin wrote:
>
>
> On Tue, 9 Oct 2018 at 23:00, Ethan Gardener wrote:
>>
>> Fascinating thread, but I think you're off by a decade with the 16-bit
>> address bus comment, unless you're not actually talking about Plan 9. The
>> 8086 and 8088 were
On Tue, Oct 9, 2018, at 8:14 PM, Lyndon Nerenberg wrote:
> hiro writes:
>
> > Huh? What exactly do you mean? Can you describe the scenario and the
> > measurements you made?
>
> The big one is USB. disk/radio->kernel->user-space-usbd->kernel->application.
> Four copies.
>
> I would like to star
people come down very hard on the pi.
here are my times for building the pi kernel. i rebuilt it a few times to push
data into any caches available.
pi3+ with a high-ish spec sd card: 23 secs
dual intel atom 1.8Ghz with an SSD: 9 secs
the pi is slower, but not 10 times slower.
However it does
> > 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
> facto
oh! you wrote a nvme driver TOO? where can i find it?
maybe we can share some knowledge. especially regarding
some quirks. i dont own hardware myself, so i wrote it
using an emulator over a weekend and tested it on a
work machine afterwork.
http://code.9front.org/hg/plan9front/log/9df9ef969856/sy
> But the reason I want this is to reduce latency to the first
> access, especially for very large files. With read() I have
> to wait until the read completes. With mmap() processing can
> start much earlier and can be interleaved with background
> data fetch or prefetch. With read() a lot more re
Well, I think 'avoid at all costs' is a bit strong.
The Raspberry Pi is a good little platform for the right applications, so
long as you are aware of its limitations. I use one as my 'always on' home
server to give me access files when travelling (the networking is slow by
LAN standards, but ok
As the guy who wrote the majority of the code that pushed those 1M 4K
random IOPS erik mentioned, this thread annoys the shit out of me. You
don't get an award for writing a driver. In fact, it's probably better
not to be known at all considering the bloody murder one has to commit
to marry hardwar
hahahahahahahaha
--
cinap
Excellent response! Just what I was hoping for!
On Oct 10, 2018, at 2:54 PM, Steven Stallion wrote:
>
> As the guy who wrote the majority of the code that pushed those 1M 4K
> random IOPS erik mentioned, this thread annoys the shit out of me. You
> don't get an award for writing a driver. In fac
On Wed, Oct 10, 2018 at 04:54:22PM -0500, Steven Stallion wrote:
> As the guy
might be worth keeping in mind the current most common use case for nvme
is laptop storage and not building jet engines in coraid's basement
so the nvme driver that cinap wrote works on my thinkpad today and is
about
> On Oct 10, 2018, at 2:54 PM, Steven Stallion wrote:
>
> You seem to be saying zero-copy wouldn't buy anything until these
> other problems are solved, right?
Fundamentally zero-copy requires that the kernel and user process
share the same virtual address space mapped for the given operation.
Th
Posted August 15th, 2013: https://9p.io/sources/contrib/stallion/src/sdmpt2.c
Corresponding announcement:
https://groups.google.com/forum/#!topic/comp.os.plan9/134-YyYnfbQ
On Wed, Oct 10, 2018 at 5:31 PM Kurt H Maier wrote:
>
> On Wed, Oct 10, 2018 at 04:54:22PM -0500, Steven Stallion wrote:
> > A
On Wed, 10 Oct 2018 at 21:40, Ethan Gardener wrote:
> >
> > Not sure I would agree with that. The 20 bit addressing of the 8086 and
> 8088 did not change their 16 bit nature. They were still 16 bit program
> counter, with segmentation to provide access to a larger memory - similar
> in principle
> Fundamentally zero-copy requires that the kernel and user process
> share the same virtual address space mapped for the given operation.
and it is. this doesnt make your point clear. the kernel is always mapped.
(you ment 1:1 identity mapping *PHYSICAL* pages to make the lookup cheap?)
the diff
For operations that matter in this context (read, write), there can be
multiple outstanding tags. A while back rsc implemented fcp, partly to
prove this point.
On Wed, Oct 10, 2018 at 2:54 PM Steven Stallion wrote:
> As the guy who wrote the majority of the code that pushed those 1M 4K
> random
On Wed, Oct 10, 2018 at 7:58 PM wrote:
> > Fundamentally zero-copy requires that the kernel and user process
> > share the same virtual address space mapped for the given operation.
>
> and it is. this doesnt make your point clear. the kernel is always mapped.
>
Meltdown has shown this to be a b
Interesting - was this ever generalized? It's been several years since
I last looked, but I seem to recall that unless you went out of your
way to write your own 9P implementation, you were limited to a single
tag.
On Wed, Oct 10, 2018 at 7:51 PM Skip Tavakkolian
wrote:
>
> For operations that mat
On Wed, Oct 10, 2018 at 8:20 PM Dan Cross wrote:
>> don't forget the code complexity with dealing with these scattered
>> pages in the *DRIVERS*.
>
> It's really not that hard. The way Linux does it is pretty bad, but it's not
> like that's the only way to do it.
SunOS and Win32 (believe it or n
On Wed, 10 Oct 2018 20:56:20 -0400 Dan Cross wrote:
>
> On Wed, Oct 10, 2018 at 7:58 PM wrote:
>
> > > Fundamentally zero-copy requires that the kernel and user process
> > > share the same virtual address space mapped for the given operation.
> >
> > and it is. this doesnt make your point clear.
On Wed, Oct 10, 2018 at 9:32 PM Bakul Shah wrote:
> Steve wrote "1:1 mapping of the virtual kernel address space such
> that something like zero-copy could be possible"
>
> Not sure what he meant. For zero copy you need to *directly*
> write to the memory allocated to a process. 1:1 mapping is
> r
25 matches
Mail list logo
