linux-kernel - Re: smart cache. ist is possible?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20090316173609.GB10814@silver.sucs.org>
Date:	Mon, 16 Mar 2009 17:36:09 +0000
From:	Sitsofe Wheeler <sitsofe@...oo.com>
To:	Alexey Fisher <bug-track@...her-privat.net>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: smart cache. ist is possible?

On Mon, Mar 16, 2009 at 08:34:53AM +0100, Alexey Fisher wrote:
> 
> If i read same somefile second time, normally will happen the same. It
> tries to read block 1 and  this is not it cache, so it will be cached
> and move block 6 out. ( |1|7|8|9|10| ) So it will complete replace
> entire cache.

Yup, that's my understanding (I'm no pro on this stuff though).
Different cache replacement algorithms will have different behviour
though (I believe Linux uses some variation on LRU -
http://linux-mm.org/AdvancedPageReplacement ).

> Or i can say, read somefile and only blocks 6-10 so i can use
> performance from cache.

Yup, you could do this but your code would have to have exactly this in
mind (e.g. skip the first 7 Mbytes THEN read 10 mbytes). There's nothing
automatic happening in this scenario from the cache's perspective -
you're just reading less so it (hopefully) doesn't become full and evict
what you want it to keep.

> Or OS need to get a list of blocks from somefile and list of cached
> blocks. And check if there is some of them cached. If they are, it
> should lock the cache, read 1-5 without caching it and read 6-10 from
> cache. After this unlock the cache. But this is not possible because
> this operation is to expensive.
> Is this what you mean?

Kinda. More like when you use memory mapped I/O (mmap) you can "lock"
pieces of the file into ram (and thus have those pieces always in
cache). See mlock -
http://opengroup.org/onlinepubs/007908799/xsh/mlock.html . There are
usually restrictions on just how much memory you can lock etc.

-- 
Sitsofe | http://sucs.org/~sits/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/