Re: [lc-devel] hello

[Bob A. <cu...@pb...>]

> That is the sort of system I am used to test and I don't have any bug
> report related to FS corruption with the latest code. The latest
> testing patch (0.24pre5) has FS corruption only when preempt patch is
> enabled. The answer to your question is: there is no warranty, but
> given our experience with swap partition, I don't think you will get
> FS corruption if using a swap partition.
yes, i don't had any :D

> > i have such machine, and in doubt, it is remote machine, so i fear
> > that i'll loose it until i'll be able to go there physically , if
> > something will go wrong (like /lib/ corruption)
hehe, it turned out that owner of internet link (using winroute to share net, 
an orthodox win user) is not allowing any tcp connections to my machine...
i lost 3 hours trying to 'see antyhing' beyond pings and finding dns names ;)
still no idea how to fix this... but everything worked fine , 
16M of ramdisk, 40M total ram, very slow hdd (1M/sec IDE without dma)
i hope i'll find a way to log in there and stress it further tommorow :>

> Using CPU idle time is on todo list too (actually, the "future work"
> list), and it may be an interesting idea to recompress. However, you
> have to decompress it twice, and that is the performance impact that
> worries me.
hmm. re-compressed (using different algorithm) pages should not take much 
cpu, those compressed twice - indeed. if you worry for performance, there
could be an option to keep some pages both compressed and uncompressed, 
nuking uncompressed pages when doing heavy i/o and in short of memory, then 
possibly recreating most used ones and keeping them uncompressed.
in modern systems CPU's are fastest and cheapest things one can have in 
computer, so i would rather not worry about this (and for users with slow 
cpu's there could be runtime/compile option to disable such features)

i would rather expect gain in performance on high-cached systems (i.e. 1M of 
L1 and 8M of L2 cache which is common on modern x86 systems) where cpu can 
benefit from having compressed data stored in L2 cache (8M is a lot if LZW 
book would be used) and then quickly decompressed to ram/L1 cache . 

if performance is an issue number of accesses of an cached page could be an 
indicator wheter to compress or not compress page . i.e. pages could be not 
cached initially , but only marked in means of frequency of access.
then when idle-mode cache compression would kick in it would compress rarely 
used pages first, then move to more frequently used ones . 
every decompressed page accessed (thresold) times could be also copied as not 
compressed, and pages used by (threshold, i.e. nice=0) processes would be 
considered as 'performance requiring' and not compressed @ all
 

>
> Regards,

-- 
--