seastarer

You can try to re-vectorize the code for larger vector size.

It's more correct to use O_DSYNC in addition to O_DIRECT. This adds FUA to the disk write if the disk requires it for durability.

It is actually very cheap if done right. Enterprise SSDs have write-through caches, so an O_DIRECT|O_DSYNC write is sufficient, if you set things up so the filesystem doesn't have to also commit its own logs.

Do these calculations take into account the lengthening of the days due to tidal friction?

They should have refused

Translating 197 M/mm2 into the dimensions of a square, we get a dimension of 71nm. If we compute the "half-pitch", that's 35.5nm.

230 M/mm2 translates to 33nm "half-pitch".

Of course, transistors aren't square and aren't so densely packed, but these numbers are more real IMO.

Now I'm imagining submarines full of illicit maple syrup

You can implement a virtual machine monitor (e.g. KVM) and then launch a Linux virtual machine to run drivers you lack.

The energy cost of extracting oxygen is higher than you'd get from burning it.

ScyllaDB is a rearchitecting of Cassandra, not just a rewrite.

Some more data on Google PD: https://raw.githubusercontent.com/scylladb/diskplorer/master...

Very odd - notice how the latency is high when the read IOPS are low. When the read IOPS climb, 95th percentile latency drops.

Looks like there is a constant rate of high latency requests, and when the read IOPS climb, that constant rate moves to a higher quantile. I'd inspect the raw results but they're quite big: https://github.com/scylladb/diskplorer/blob/master/latency-m...

Background: https://github.com/scylladb/diskplorer/

No.

Persistent Disk read latency is usually good, but jitters up to 100ms. The scheduler can compensate for high latency (essentially applying Little's Law) but cannot compensate for jitter without saturating the disk.

Specialized logging applications, databases, userspace filesystems, and virtual machine monitors.

It happens sometimes. Very often? Not in my experience

Multi-Terabyte SSDs are very common. An i3.16xlarge instance on AWS, for example, has 15TB of SSD storage.

> If you know your read and write patterns very well you can effectively use this for nearly asynchronous IO without the pains of AIO and few to none extra threads.

This may work for sequential reads, but not for random reads.

The diagrams are now correct (the read/write diagram was placed under the mmap section by mistake).

I see what happened, the read/write diagram got placed under mmap.

Right, the mmap read hit is incorrect, I'll fix it up.

You're going to be right on that guess. It will take some time though.

We plan to reduce power usage on low load eventually.

It ought to. There may be a minor porting effort involved. Note you need very recent gcc.

Thanks. We "disable" C-states by polling -- the cpu never goes idle. This is partly because dpdk doesn't support interrupts, and partly because using interrupts is a major performance hit. We have plans to improve this, but nothing committed yet.

Do you have a link to this cluster-on-die mode?

In posix mode, seastar uses the host's TCP stack (instead of the internal super-fast stack). This is useful for development. While we haven't ported it to osx, it should be fairly easy as the code is portable.

Note you'll need gcc 4.9 or later.