11.04.2012 11:20, Erich Titl написал: > Hi Andrew > > at 23.04.2012 10:07, Andrew wrote: >> 11.04.2012 09:36, Erich Titl написал: >>> Hi Andrew >>> >>> at 22.04.2012 23:20, Andrew wrote: >>>> Hi all. >>>> I'm thinking about some improvements that can be useful in future, >>>> especially on tiny systems, and that should be added before 5.0-beta >>>> release if they'll be accepted as useful: >>>> >>>> 1) Split single solid initrd to multiple files, for ex. - basic initrd >>>> with binaries, and additional files with kernel modules (usb variant, cd >>>> variant, etc). Syslinux supports multiple initrds: >>> Does Grub support them too? >> Yes. > Could you refer me to the docs? http://en.gentoo-wiki.com/wiki/Initramfs#Multiple_initramfs >>>> http://www.syslinux.org/wiki/index.php/SYSLINUX#INITRD_initrd_file >>>> This can save some valuable space on tmpfs. Also this allows to add >>>> single arch-independent initrd, and arch-dependent initrd additions with >>>> modules. >>> Sounds reasonable, but see above. I believe the cpio initrd can be >>> concatenated to a single file. >> I think that concatenating isn't a good idea. But repacking from 2 cpio >> archives to one image is possible in any case. >> >> Also there is a possibility to integrate some of initramfs into kernel >> image. >>>> 2) Add support of zram - compressed ramdisk (compressed block device in >>>> memory, which can be used as swap or as base device for some >>>> filesystem). But I still unsure in what way we should use it: as typical >>>> 'swap in RAM' device, or as block device(s) instead of tmpfs ones. In >>>> 1st case tmpfs should be pushed in the 'swap' first, and it looks more >>>> flexible, but 2nd case has it's own advantages. >>> Would the compression overhead on slow (tiny) machines not overcome the >>> benefits? Actually we don't need swap at all, and then having it to >>> compress/decompress mhhhh.... >>> >>> cheers >>> >>> Erich >>> >> This can be switcheable feature. 'swap' will be used for rarely-accesed >> data, and compression/decompression speed of LZO is enough high (just >> 2-3 times lesser that access to uncompressed ramdisk on modern hardware; >> for legacy hardware it'll require testing - but I don't think that it'll >> be dramatically slow; LZO is enough fast algorithm). It'll be good for >> log storing (which can be up to some hundreds of MBs per day) and so on. > I was refering to the swap file where IMHO compression is a resource > hog. A compressed filesystem for logging would be good. > > cheers > > Erich In case of using zram swap, first rarely used tmpfs content will be 'swapped', then - rarely used program memory. Intensive swapping is possible only in one case - if there are too low free memory for all processes.
------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
