On Jan 15 2016, Nikhilesh Reddy <reddyn@xxxxxxxxxxxxxx> wrote:
> Our local benchmarks on embedded devices (where power and cpu usage is
> critical) show that splice doesnt help as much .. when running
> multiple cpu's results in increased power usage
>
> The below results are on a specific device model.
>
> Where IOPS is number of 4K based read or writes that could be performed each second.
>
> regular spliced Stacked I/O
> sequencial write (MiBPS) 56.55633333 100.34445 141.7096667
> sequencial read (MiBPS) 49.644 60.43434 122.367
>
> random write (IOPS) 2554.333333 4053.4545 8572
> random read (IOPS) 977.3333333 1223.34 1432.666667
>
> The above tests were performed using a file size of 1GB
That looks convincing to me.
> Also we can called it FUSE_DELEGATED_IO if that helps :).
> I chose to call is stacked i/o since we are technically stacking the
> fuse read/writes on the ext4/fat or other filesystems.
Yeah, but "stacked" has a pretty strong association with union/overlay
file systems (as you have seen), and the feature is not at all specific
to that usecase.
For example, many FUSE file systems store data in some remote server
over the network but cache it on a local disk. The access to the cached
data would benefit from the feature under discussion, but I have a hard
time thinking of such a FUSE file system being "stacked" on the file
system that happens to hold its cache.
Best,
-Nikolaus
--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
