Non-volatile Storage: CPUs no longer more performant than I/O devices
81–90 of 121 posts
Re: Non-volatile Storage: CPUs no longer more performant than I/O devices
#82Performant: still not a word.
Re: Non-volatile Storage: CPUs no longer more performant than I/O devices
#83This is with a Skylake Xeon E3-1275, 64GB ECC UDIMM, and Intel 750 PCIe SSD (probably the fastest setup you can get).
It looks like I have to figure out something that tunes Postgres to account for the fact that disk lookups are no-cost.
Re: Non-volatile Storage: CPUs no longer more performant than I/O devices
#84Earlier quoted context omitted.
This sounds interesting, but why should this be a new piece of hardware as opposed to a new OS service? Are these functions simply so specialized that implementing them in the OS would be a bottleneck (even though the CPU has plenty of free cycles)?
"This sounds interesting, but why should this be a new piece of hardware as opposed to a new OS service?" Because the entire point is that CPUs are too slow by themselves, even without the OS, let alone with it. While you were context-switching into this OS server you missed the chance to do 10 IOPs give or take an order of magnitude. Yet the OS really can't go anywhere. We can sometimes poke a hole here and sometime…
Re: Non-volatile Storage: CPUs no longer more performant than I/O devices
#85HP was designed a "flat memory" OS based on vast amounts of cheap memrister memory http://www.technologyreview.com/featuredstory/536786/machine... . But when I googled gfor this article I saw the project has been delayed.
If you're interested in talking about this more (especially if you're in the SF Bay Area), my email is in my profile.
Re: Non-volatile Storage: CPUs no longer more performant than I/O devices
#86Earlier quoted context omitted.
The syscall overhead isn't the problem, that's dirt cheap as you say. The problem is the context-switch overhead. Calling into the OS flushes a lot of data and instructions from the cache, and that lost performance after returning can easily add up to around 30µs.[1] [1] http://blog.tsunanet.net/2010/11/how-long-does-it-take-to-ma...
Sounds like multiple caches are an obvious solution. No code in the OS needs access to the user code or data cache, and vice versa. Smart cache management might be one of Intel's goals for the Altera buyout.
This is not true for the data. How do you pass any data structures outside CPU registers then, say the path to a file to open. Normally it's a char*[0] (indeed passed in a register) but then the OS actually reads the data off the process memory (L1 data cache usually)
Re: Non-volatile Storage: CPUs no longer more performant than I/O devices
#87I'm seeing this on a new Postgres database server: my cache miss and cache hit queries take virtually the same time! This is with a Skylake Xeon E3-1275, 64GB ECC UDIMM, and Intel 750 PCIe SSD (probably the fastest setup you can get). It looks like I have to figure out something that tunes Postgres to account for the fact that disk lookups are no-cost.
That's likely because it's hitting the OS's page cache.
Re: Non-volatile Storage: CPUs no longer more performant than I/O devices
#88I've made that point before on YC.[1] We need to view fast storage as something other than a disk accessed through the OS, and other than slow RAM accessed as raw memory. Access through the OS is too slow, and access as raw memory is too risky. What's probably needed is something like a GPU sitting between the CPU and the fast persistent storage. Call this an SPU, or "storage processing unit." What would such a devic…
Wrapping a bunch of replies into one: Absolutely agree that we need to view fast storage as something other than disk behind a block interface and slow memory, especially with all the different flavours of fast persistent storage that seem to be on the horizon. For the one's that attach to the memory bus, the PMFS-style [1] approach of treating them like a file-system for discoverability and then mmaping to allow them to be accessed as memory is pretty attractive.
I'm not sure a dedicated storage processing unit is the way to go though; I think we could equally well see bits of functionality being offloaded to smarter controllers (kind of like checksum, VLANs, etc are on network adapters) while the CPU remains in charge of orchestrating the different bits.
Also agree on the fact that it is an interesting data structure problem -- a lot of the work we do involves examining what the right data structures are for things once seeks are free and cache locality is the dominant factor for operations.
Re: Non-volatile Storage: CPUs no longer more performant than I/O devices
#89Earlier quoted context omitted.
This word is one of my pet peeves as well. "Performant" is an ignorant and foolish way to say "high performance". It's like saying "voltant" instead of "high voltage". I'm all for coining new words that mean new things, but when someone says "performant" I treat it as a clue that they might be a sloppy thinker.
I don't like "performant" as a word, but I also recognize that is an irrational, emotional reaction on my part. I think it's valid to create an adjective that basically means "a thing that has high or acceptable performance". I see no reason to conclude people who use it are sloppy thinkers.
Re: Non-volatile Storage: CPUs no longer more performant than I/O devices
#90Please excuse my ignorance on this matter but will this technology have any impact on the hierarchy levels below disk (i.e. RAM and CPU caches)? Compared to Register, L1 and L2 access RAM access is still really slow. Will non-volatile storage latencies rival or exceed those of standard RAM? From how I understand the article it's primarily disk IO speed that's affected, correct?
I'm not sure what the future holds in terms of latencies for non-volatile storage but sub-DRAM levels aren't within reach yet.