Am 12.12.2012 02:40, schrieb Frank Steinmetzger: > On Tue, Dec 11, 2012 at 09:20:55PM +0100, Florian Philipp wrote: > >>> * From my observations, the benefit of 64 bit over 32 is much smaller for an >>> Atom than it is for my Core2. Am I right to assume thus that the Atom >>> architecture doesn’t have much to offer to 64 bit (such as extra >>> registers)? >>> I’m not talking about memory here, since it’s limited to 2 GB in any case. >>> >> >> It has the same set of registers as your Core2. > > Incidentally, when I initially set up the netbook, the output of > gcc -march=native -E -v - </dev/null 2>&1 | sed -n 's/.* -v - //p' > (which floated around the ML in the past) implied core2, IIRC. > >> It's just that the Atom micro-architecture is terrible with regard to >> 64bit. That's just about the only reason that x32 was invented (and >> now that I've said it, I'm just waiting for the flamewar about it). > > Terrible in what way? Inadequate memory throughput? I didn't know x32, > but from what I've read in the last few minutes it sounds intriguing. >
Just citing Flameeyes who is citing Intel. http://blog.flameeyes.eu/2012/06/debunking-x32-myths [...] >>> I sped up the installation process for 32 bit by using a chroot on the big >>> machine, which worked nicely. But it’s not a long-term solution, b/c it >>> uses up too much disk space on the host. >> >> I do the same using NFS, bind mounts and tmpfs. What do you mean by disk >> space? > > That I don't have much space left on the host machine for the entire > chroot. I bind-mount distfiles and portage, but I'm still running low > on gigabytes. > I was thinking of NFS quite early, but a friend said it would perform > not nicely. Also, with all my cables currently occupied, the two are > connected over a slow WiFi router. It's one of the rare cases in which > compressing distcc traffic increases performance. :) The netbook has > gigabit ethernet, though. Thank $DEITY for compressed tar pipes over > SSH. I wonder what Windows people would do in such a situation. >:-] > I see. Yep, wifi is really not a good choice for this. NFS works nice, though. I just ran into some minor trouble when setuid bits would not survive merging. Haven't debugged this yet as it's easy enough to find with a script. [...] >>> * The last thing I’m going to set up is filesystem encryption, at least for >>> ~. >>> I already know/think that AES would be the best choice due to limited CPU >>> power, but what else is there to heed besides key size? >> >> Nothing, you're good. Hash and key chaining method have negligible >> impact. If you stick with an x86_32 userspace I suggest at least using >> an x64 kernel so you can use of CRYPTO_AES_X86_64. > > That's an interesting idea. If I had a 32 bit userland, I would have to > build new kernels on my big 64 laptop then, right? I don’t suppose I > can simply mix chosts, such that I would have a multilib x86_64 > gcc/binutils/glibc, but i686 everything else. > Try this. http://www.gossamer-threads.com/lists/gentoo/user/190919 > I haven't done any comparisons of 32/64 crypto yet, I'm just reading > docs on Luks (never used it before). Big stuff (videos, music) won't be > encrypted anyway, just the sensitive data like mail, documents, > passwords and personal photos. So the requirements won't be high. > However I might expand it to /, though that would involve a more > complicated boot process (I never needed initrds except for bootsplash). > I personally see no reason for encrypting root as there is nothing of interest in there. I just encrypt home, certain /var/* sub-mounts and other stuff. That way, you can use /etc/init.d/dmcrypt.Actually, I've tweaked the setup so that I can have LVM on top of Luks. If you're interested, I can share the change. > On a sidenote, While I was cleaning up unread mails in the ML, I just > found your interesting frontswap/zcache trick. > > I wonder how many years I'd have to use the device to get back the time > from improved performance that I spent setting it up in the first place. > :-D > Consider it experience. ;-) Regards, Florian Philipp
signature.asc
Description: OpenPGP digital signature
