Hacker News Reader

Comment by qiqitori | Hacker News Reader

> Consider, for example, an application that is reading sequentially through a file. Each page of the file will be put into the page cache as it is read, but the application will never need it again; in this case, recent access is not a sign that the page will be used again soon.

Going off on a tangent here, but I've always felt there should be an easy way to read through files without causing the kernel to cache them into memory. When I grep through the odd multi-GB file I sometimes/often don't want that to be cached. Looking through the flags for open(2) I see O_DIRECT. Wonder if it'd make sense to expose that as an option in grep, or if there's a handy library somebody made that I could preload to anything to get that effect.

View on HN

nocache¹. It is LD_PRELOAD based so will only function within the normal limitations of that. It also comes with a couple of tools for examining and modifying a file's cache state, which makes it useful to judge its value in your environment.

One of my biggest use cases for it is with soxi, which I use solely for playlist manipulation. I don't alias my source tree search tools, because invariably I'm going to want all that stuff in the cache anyway for builds and such.

¹ https://github.com/Feh/nocache

Also comes with the nifty cachestats tool which tells you how much of a file is currently cached. And is packaged by Debian so you can apt-get it.

No need to make it an option for each text util. We use an O_DIRECT version of the (z)cat command as the start of pipelines with big files.

Nice tip, thanks.

Related: The experimental async aware (io_uring optimized) Glommio API may eventually supplant POSIX I/O.

https://github.com/DataDog/glommio

"Modern storage is plenty fast. It is the APIs that are bad." https://itnext.io/modern-storage-is-plenty-fast-it-is-the-ap...

except that the fastest (and also parallel) versions of grep tend to use memory mapping. for grep it tends to be more linear (except the parallel case), but for others like sort it might not be the case that linear access to the file is always best.

I'm not aware of an O_DIRECT version of cat. The (older) GNU cat (GNU coreutils 0.83) I just looked at doesn't seem to support it.

There is however GNU dd which supports direct i/o ('direct' flag) for ages.

That caching is pretty much free with only one exception: it might evict other cached pages.

> When I grep through the odd multi-GB file I sometimes/often don't want that to be cached.

What are you hoping to gain here? The only place I could imagine this might be an issue is on a HDD-using (as opposed to SSD) server that serves a lot of files, which you might evict with your grepping, causing a lot of random IO activity later because the server needs to read everything from disk again to serve requests.

But as a "odd" one-off I probably just wouldn't care.

It might swap out memory too.

I'd like to see the kernel figure this out automatically. If the last 100,000 files opened by grep were never accessed again, is it a good bet to cache the 100,001'st?

I think the solution is not to come up with clever heuristics, but to use a tiny neural net which predicts "how many hours till this page is accessed again?".

Train the net using a tiny sample of reads and writes.

Obviously the net needs to be really tiny to run on every single page read, but I believe even say a network with 50 weights would outperform today's heuristics.

please...submit patches if you can, with benchmarks as well, so that the idea can perhaps be evaluated empirically ?

In a previous comment[1] I mentioned finding a paper that made a neural net cache predictor with seemingly great success.

A key thing however was that their actual predictor was a simpler model, SVM, designed using insight discovered from the behavior of the neural network one. In particular the source address was a strong indicator for the model.

[1]: https://news.ycombinator.com/item?id=26455515

My first intuitive thought is "gosh, please, don't". It sounds like a crazy idea to integrate a neural net to everything - it might work in the 99.999% cases, but when something like this fails, good luck debugging it, re-training the network and then verifying if your improvement helped on a tight schedule. And it's also a dangerous architectural paradigm - will we end up with syscalls deciding which side effects happen deciding on whether the neural network things the file is going to be useful in the future?

I don't argument for excess simplicity, but if you can't explain (critical) behavior of your code without referring to a big matrix of NN weights, it's probably a bad idea.

As I noted in my previous comment I had a similar gut reaction. However reading the paper, for me the most interesting conclusion was this:

Thus, this paper has shown how we can use deep learning in an offline setting to derive insights that lead to an improved set of features with which to make predictions for cache replacement. More broadly, our approach in designing Glider suggests that deep learning can play an important role in systematically exploring features and feature representations that can improve the effectiveness of much simpler models, such as perceptrons and SVMs.

does the kernel now support floating point operations ?

I'm no kernel developer so I don't know. The dataset they used for training the neural net was a recorded dataset, so training could be done offline.

The specific predictor they created was integer based, so could be used in a non-floating point kernel:

We then use an SVM with the k-sparse binary feature. Since integer operations are much cheaper in hardware than floating point operations, we use an Integer SVM (ISVM) with an integer margin and learning rate of 1.

Again this highlights the interesting point of the paper, IMHO.

I feel like if you already know exactly how you're about to access the data, then it would be more efficient to be able to just tell the kernel rather than making it figure it out on its own. At the minimum, the first accesses would perform better since it wouldn't have to waste time learning.

This is why instructions like dcbz exist on POWER - to tell it to not bother reading in the next cache line because you're about to write to it.

A tweak: it may be that application access patterns are inefficient WRT block I/O, so that some caching (e.g. read-ahead) is useful but should be aggressively expired.

There was some work done on a RWF_UNCACHED flag a while back, but I'm not sure if it went anywhere. It was supposed to use the page cache if the page is already there, but not add it (or at least not keep it around) if it isn't.

Reply on news.ycombinator.com