On 8/28/20 5:59 PM, antlists wrote:
On 28/08/2020 23:40, Ram Ramesh wrote:
On 8/28/20 5:12 PM, antlists wrote:
On 28/08/2020 18:25, Ram Ramesh wrote:
I am mainly looking for IOP improvement as I want to use this RAID
in mythtv environment. So multiple threads will be active and I
expect cache to help with random access IOPs.
???
Caching will only help in a read-after-write scenario, or a
read-several-times scenario.
I'm guessing mythtv means it's a film server? Can ALL your films (or
at least your favourite "watch again and again" ones) fit in the
cache? If you watch a lot of films, chances are you'll read it from
disk (no advantage from the cache), and by the time you watch it
again it will have been evicted so you'll have to read it again.
The other time cache may be useful, is if you're recording one thing
and watching another. That way, the writes can stall in cache as you
prioritise reading.
Think about what is actually happening at the i/o level, and will
cache help?
Cheers,
Wol
Mythtv is a sever client DVR system. I have a client next to each of
my TVs and one backend with large disk (this will have RAID with
cache). At any time many clients will be accessing different programs
and any scheduled recording will also be going on in parallel. So you
will see a lot of seeks, but still all will be based on limited
threads (I only have 3 TVs and may be one other PC acting as a
client) So lots of IOs, mostly sequential, across small number of
threads. I think most cache algorithms should be able to benefit from
random access to blocks in SSD.
Do you see any flaws in my argument?
I don't think you've understood mine. Doesn't matter what the cache
algorithm is, the whole point of caching is that - when reading - it
is only a benefit if the different threads are reading THE SAME bits
of disk. So if your 3 TVs and the PC are accessing different tv
programs, caching won't be much use, as all the reads will be cache
misses.
As for writing, caching can let you prioritise reading so you don't
get stutter while watching. And it'll speed things up if you watch
while recording.
But basically, caching will really only benefit you if (a) your cache
is large enough to hold all your favourite films so they don't get
evicted from cache, or (b) you're in the habit of watching while
recording, or (c) two or more tvs are in the habit of watching the
same program.
The question is not "how many simultaneous threads do I have?", but
"how many of my disk i/os are going to be cache misses?" Your argument
actively avoids that question. I suspect the answer is "most of them".
Cheers,
Wol
I do not know how SSD caching is implemented. I assumed it will be
somewhat similar to memory cache (L2 vs L3 vs L4 etc). I am hoping that
with SSD caching, reads/writes to disk will be larger in size and
sequential within a file (similar to cache line fill in memory cache
which results in memory bursts that are efficient). I thought that is
what SSD caching will do to disk reads/writes. I assumed, once reads
(ahead) and writes (assuming writeback cache) buffers data sufficiently
in the SSD, all reads/writes will be to SSD with periodic well organized
large transfers to disk. If I am wrong here then I do not see any point
in SSD as a cache. My aim is not to optimize by cache hits, but optimize
by preventing disks from thrashing back and forth seeking after every
block read. I suppose Linux (memory) buffer cache alleviates some of
that. I was hoping SSD will provide next level. If not, I am off in my
understanding of SSD as a disk cache.
Regards
Ramesh
