Visualizzazione stampabile
-
Quote:
Originariamente inviato da
imre
Se l'algoritmo in uso è il Lempel-Ziv-Mqualcosa la compressione teorica si avvicina al 67,5% (mi son fatto due conti, magari ho sbagliato qualcosa) , quindi probabilmente l'algoritmo usato può essere ottimizzato ulteriormente, oppure imporre un secondo passaggio con l'algoritmo Lempel-Ziv-Wqualcosa.....
La compressione teorica è ben diversa da quella reale, che dipende dai tipi di dati usati: ogni algoritmo è indicato per un determinato aspetto della codifica dei dati (codice binario, testo, numeri, ecc). Non so quale sia il "target" ideale dello LZMA, ma quanto a compressione impacchettata e ZRAM non l'ho mai visto fare il 67%... Comunque una seconda passata come ho sottolineato prima non servirebbe a nulla, perché tutti i pattern ricercati dall'algoritmo spariscono una volta che i dati sono compressi (possono essere ritrovati altri pattern da comprimere solo in casi casuali e fortuiti), quanto all'ottimizzazione è già lui stesso un'ottimizzazione del LZ77 (1977), non so che ci possano ancora fare sopra
Comunque riferimenti: A Quick Benchmark: Gzip vs. Bzip2 vs. LZMA
L'unica sarebbe fare in modo che la ZRAM comprima in GZIP
-
LZW è una versione del LZMA ottimizzata per le immagini ed i suoni. Quello che mi frullava per la testa era un primo passaggio che comprimesse le immagini(ogni app ne è strapiena) ed un secondo i "dati", riuscendo così a recuperare qualche altro mb, che considerando l'enorme quantitativo di memoria a disposizione del nostro telefono, magari male non gli fa. Ovviamente io parlo da noob-autodidatta, quindi decifra quello che cerco di comunicare XD
ps. interessante quel confronto
edit: pardon non consideravo una cosa molto importante, maggiore compressione = maggior numero di cicli . Forse non è il caso di spingere oltre :)
edit2: ho trovato questo articolo abbastanza carino in-kernel memory compression
-
Quote:
Originariamente inviato da
imre
edit: pardon non consideravo una cosa molto importante, maggiore compressione = maggior numero di cicli . Forse non è il caso di spingere oltre :)
Esatto: più passaggi di compressione fai più impegni la CPU in quel compito (pressochè inutile a un certo punto) di compressione-decompressione e si rischia di arrivare a un punto che la CPU fa solo più quello e non si occupa più di eseguire il resto
Comunque per le modifiche che proponi tu sarebbe da modificare il .c della ZRAM, a patto di sapere dove e come mettere le mani e per quanto conosca abbastanza profondamente il linguaggio C, mi mancano alcune nozioni di programmazione di sistema (argomento del 4 anno di Ing. informatica al Politecnico di Torino) e del corso di Sistemi Operativi (di cui non sono riuscito a seguire il corso purtroppo)
-
Se in questo kernel funzionerà a dovere l' otg sarò il primo a flasharlo:-):-).
Inviato dal mio GT-S7500 usando Androidiani App
-
Modificate impostazioni ZRAM per migliori prestazioni ;)
-
Grande lox ;)
Inviato dal mio GT-S7500 usando Androidiani App
-
Suggerite da imre che ringrazio :p
-
Grazie a tutti e due :D
Inviato dal mio GT-S7500 usando Androidiani App
-
Ho compilato un kernel con il trebon05_defconfig... Subway Surfer si riavvia comunque anche se dopo più tempo... Avendo messo un Kernel "stock" e avendo levato i tweaks per init.d, ne deduco che il problema sta nel build.prop...
Qualche idea?
-
prova ad aumentare la soglia del kernel panic scarica system tuner, da li puoi modificare a caldo i parametri del kernel. La modifica genera uno script in init.d che ovviamente richiede il riavvio.