Pomaly system! - slow memory support

[Pavel Machek]

Ahoj!

> : > : -> Takze mas stejny problem jako ja: Necachovatelna RAMka. Rozdil je v
> : > : -> tom, ze ja na to mam patch do kernelu (vlastni vyroby). Horni pamet se
> : > : -> pak pouziva vyhradne jako diskova cache. Jestli ma nekdo zajem, at mi
> : > : -> posle maila.
> : > : 
> : > : navrhujem to poslat linusovi, nech to hodi do novych vyvijanych kernelov;
> : > : urcite sa tomu kopa ludi potesi...
> : > 
> : > 	Pokud se nepletu, tohle Pavel uz zkousel ...
> : 
> : Nezkousel jsem to, Linus zahazuje i podstatne cistsi patche. A tohle
> : je aspon v aktualni versi silne necisty patch, o kterym to vim dokonce
> : i ja. Pro me funguje, ale neni to dobra vec (tm). [Ono: je vubec
> : otazka jak by pripadny support pro pomalou ramku mohl vypadat. Co s
> : tou ramkou? Jen diskova cache? To neni optimalni, co kdyz rychla ramka
> : dojde? ... Jestli nekdo zna reseni, SEM S NIM!]
> : 
> 	Jedna moznost je napsat specialni block device driver pro pomalou
> ram, ktery by fungoval podobne jako loop, ale provadel by caching.

Ugly, protoze ve chvili kdy bude dochazet RAMka se bude zurive
swappovat, ale nekde bude viset par megu ramky vyhrazeny pro cache
ktera se nebude pouzivat. Presneji bude ale na cachovani ktery tou
dobou vubec nebude potreba.

> Na druhou stranu toto by prineslo vic kopirovani, nez je zdravo.
> Tezko rict. Co dela ten tvuj patch?

Veskere alokace s GFP_BUFFER jdou prednostne do pomale RAMky, veskere
ostatni alokace jdou *vzdy* do rychle RAMky. V podstate ekvivalentni
tvemu reseni az na ten detail ze to bylo mnohem jednodussi napsat...

-- 
I'm really pavel na atrey.karlin.mff.cuni.cz. 	   Pavel
Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-).