[KERNEL] Nuovo Custom Kernel Per GT-S7500 by Lox

[loxdegio]

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

[imre]

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

[loxdegio]

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)

[AndTab]

Se in questo kernel funzionerà a dovere l' otg sarò il primo a flasharlo:-):-).


Inviato dal mio GT-S7500 usando Androidiani App

[loxdegio]

Modificate impostazioni ZRAM per migliori prestazioni

[mark5]

Grande lox


Inviato dal mio GT-S7500 usando Androidiani App

[loxdegio]

Suggerite da imre che ringrazio

[mark5]

Grazie a tutti e due


Inviato dal mio GT-S7500 usando Androidiani App

[loxdegio]

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?

[imre]

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.