Re: [gentoo-user] which machine to buy for perfect gentoo machine?!
On 04/14/2013 01:55 AM, Pandu Poluan wrote: On Apr 14, 2013 1:42 AM, Michael Mol mike...@gmail.com mailto:mike...@gmail.com wrote: [snip] What I meant was: given 4 physical AMD cores (but only 2 FPUs, courtesy of AMD's Bulldozer/Piledriver arch) vs 4 virtual Intel cores (2 cores split into 4 by Hyperthreading), I undoubtedly prefer 4 physical ones. (Of course if the Intel CPU has 4 pphysical cores, it should be compared with an 8-core AMD CPU). I had some lively discussion on AMD vs Intel *for virtualization* in the Gentoo Community on Google+, which referenced a thread on ServerFault. The conclusion was: Intel CPUs (provided they support VT-x) can run baremetal virtualization as well as AMD, in the majority of cases. It's the minority of cases -- edge cases -- that I'm concerned with. And, lacking the money to actually buy 2 complete systems to perform comparison, I'll take the safe route anytime. Yes, Intel's top-of-the-line processors might be faster than AMD's, but the latter is cheaper, and exhibited a much more 'stable' performance (i.e., no edge cases to bite me later down the road). That said, I read somewhere about the 'misimplementation' of some hypercalls in Intel CPUs... in which some hypercall exceptions are mistakenly handled by the Ring 0 hypervisor instead of the Ring 1 guest OS, thus enabling someone to 'break out' of the VM's space. This misimplementation is exploitable on KVM and Xen (the latter, my preferred baremetal virtualization). That's actually very interesting. I hadn't heard about this. I much prefer having 4 actual cores than 4 virtual cores (only 2 actual cores); less chance of things messing up royally if I hit some edge cases where Hyperthreading falls flat on its face. Whatever works. I'll note that AMD's piledriver core does something very complementary to hyperthreading. Where HT uses some circuitry to avoid context switching when changing whether a core is handling one thread vs another thread, Piledriver has a small number of physical front-end cores dispatching to a larger number of backend pipelines. It's a very curious architecture, and I look forward to seeing how it plays out. HT and Piledriver are conceptually very similar when you look at them in the right way...Piledriver might be seen as a more general approach to what HT does. True. The main complexity is when an instruction requires access to the FPU, since there's only one FPU per two GP cores. This will somewhat impact applications that uses the FPU heavily... except if they can switch to OpenCL and leverage the embedded Radeon on AMD's so-called APUs. Intel's on-die GPGPU looks promising in that regard, too. As a guy who likes to do heavy bulk float crunching in HDR imagery, I'm looking forward to OpenCL improvements. Personally, I've enjoyed both Intel and AMD processors. Last I assembled a system, Intel's midrange offered more bang for the buck than AMD, but Intel's midrange part was also much more expensive. OTOH, AMD systems could be upgraded for piece by piece for much, much, much longer, whereas Intel systems tended to require replacing many more parts at the same time. That was about five years ago, though...I don't know exactly where things sit today. I'd start with the cpubenchmarking.net http://cpubenchmarking.net CPU value listing, and find the best-value part that has the performance degree I'm looking for. http://cpubenchmark.net/cpu_value_available.html I might also cross-reference that page with this one: http://cpubenchmark.net/mid_range_cpus.html True. My desktop computer died on me about 6 months ago. It was 4.5 years old at the moment of death. It had served me very well. That said, my brother had just purchased an AMD system (store-assembled) with an FX-8350, and he said that it's faster than anything he's ever used before, and he's used many high-end systems in his job (he's a Petroleum Geologist, his line of work involves analyzing a HUGE amount of data to find out the 'oil potential' of an area, to give his company a ballpark figure on how much to bid for the exploitation rights to the area). My desktop box has two Xeon E5345s. When I looked it up, I was amazed that the FX-8320 has *twice* the cpumark score as the E5345. (Still doesn't make sense to replace what I have, though; the difference in power bill would take a few years to pay for the parts.) The FX-8320 looks promising. Now if only desktop motherboard manufacturers would add IPMI... If buying an Intel part, I'd be very, very careful to make sure that it supported all the features I want. I've been bit by that on this laptop...I had no idea it wouldn't have VT-x. I almost got bitten by this: My previous employer had wanted to purchase a lot of new workstations. Luckily before the PO came out, I double checked the specs. When I found out that the particular model we were offered does not support VT-x, I
Re: [gentoo-user] which machine to buy for perfect gentoo machine?!
On Apr 14, 2013 1:27 PM, Michael Mol mike...@gmail.com wrote: On 04/14/2013 01:55 AM, Pandu Poluan wrote: On Apr 14, 2013 1:42 AM, Michael Mol mike...@gmail.com mailto:mike...@gmail.com wrote: [snip] What I meant was: given 4 physical AMD cores (but only 2 FPUs, courtesy of AMD's Bulldozer/Piledriver arch) vs 4 virtual Intel cores (2 cores split into 4 by Hyperthreading), I undoubtedly prefer 4 physical ones. (Of course if the Intel CPU has 4 pphysical cores, it should be compared with an 8-core AMD CPU). I had some lively discussion on AMD vs Intel *for virtualization* in the Gentoo Community on Google+, which referenced a thread on ServerFault. The conclusion was: Intel CPUs (provided they support VT-x) can run baremetal virtualization as well as AMD, in the majority of cases. It's the minority of cases -- edge cases -- that I'm concerned with. And, lacking the money to actually buy 2 complete systems to perform comparison, I'll take the safe route anytime. Yes, Intel's top-of-the-line processors might be faster than AMD's, but the latter is cheaper, and exhibited a much more 'stable' performance (i.e., no edge cases to bite me later down the road). That said, I read somewhere about the 'misimplementation' of some hypercalls in Intel CPUs... in which some hypercall exceptions are mistakenly handled by the Ring 0 hypervisor instead of the Ring 1 guest OS, thus enabling someone to 'break out' of the VM's space. This misimplementation is exploitable on KVM and Xen (the latter, my preferred baremetal virtualization). That's actually very interesting. I hadn't heard about this. Here you go: http://blog.xen.org/index.php/2012/06/13/the-intel-sysret-privilege-escalation/ It's CVE-2012-0217, and the guys from vupen actually has created a working proof: http://www.vupen.com/blog/20120904.Advanced_Exploitation_of_Xen_Sysret_VM_Escape_CVE-2012-0217.php Rgds, --
Re: [gentoo-user] which machine to buy for perfect gentoo machine?!
On 04/14/2013 04:32 AM, Pandu Poluan wrote: On Apr 14, 2013 1:27 PM, Michael Mol mike...@gmail.com mailto:mike...@gmail.com wrote: On 04/14/2013 01:55 AM, Pandu Poluan wrote: On Apr 14, 2013 1:42 AM, Michael Mol mike...@gmail.com mailto:mike...@gmail.com mailto:mike...@gmail.com mailto:mike...@gmail.com wrote: [snip] What I meant was: given 4 physical AMD cores (but only 2 FPUs, courtesy of AMD's Bulldozer/Piledriver arch) vs 4 virtual Intel cores (2 cores split into 4 by Hyperthreading), I undoubtedly prefer 4 physical ones. (Of course if the Intel CPU has 4 pphysical cores, it should be compared with an 8-core AMD CPU). I had some lively discussion on AMD vs Intel *for virtualization* in the Gentoo Community on Google+, which referenced a thread on ServerFault. The conclusion was: Intel CPUs (provided they support VT-x) can run baremetal virtualization as well as AMD, in the majority of cases. It's the minority of cases -- edge cases -- that I'm concerned with. And, lacking the money to actually buy 2 complete systems to perform comparison, I'll take the safe route anytime. Yes, Intel's top-of-the-line processors might be faster than AMD's, but the latter is cheaper, and exhibited a much more 'stable' performance (i.e., no edge cases to bite me later down the road). That said, I read somewhere about the 'misimplementation' of some hypercalls in Intel CPUs... in which some hypercall exceptions are mistakenly handled by the Ring 0 hypervisor instead of the Ring 1 guest OS, thus enabling someone to 'break out' of the VM's space. This misimplementation is exploitable on KVM and Xen (the latter, my preferred baremetal virtualization). That's actually very interesting. I hadn't heard about this. Here you go: http://blog.xen.org/index.php/2012/06/13/the-intel-sysret-privilege-escalation/ It's CVE-2012-0217, and the guys from vupen actually has created a working proof: http://www.vupen.com/blog/20120904.Advanced_Exploitation_of_Xen_Sysret_VM_Escape_CVE-2012-0217.php Interesting! It also sounds like it's reasonably generally fixed with a patch to the hypervisor. Too bad hypervisors tend to have extremely long uptimes. signature.asc Description: OpenPGP digital signature
[gentoo-user] compile large packages outside /var/tmp/portage/
How to configure portage not to compile large packages (eg. firefox, thunderbird etc) in /var/tmp/portage/ (RAM disk)? I have only assign 4GB and these packages need more room to compile. -- Joseph
Re: [gentoo-user] compile large packages outside /var/tmp/portage/
PORTAGE_TMPDIR=/tmp/ying/portage_tmpdir BUILD_PREFIX=/tmp/ying/build_prefix DISTDIR=/tmp/ying/distdir PORTDIR=/tmp/ying/portdir These are the configurations in my make.conf. Details can be found in make.conf(5). -- yegle http://about.me/yegle On Sunday, April 14, 2013 at 2:33 PM, Joseph wrote: How to configure portage not to compile large packages (eg. firefox, thunderbird etc) in /var/tmp/portage/ (RAM disk)? I have only assign 4GB and these packages need more room to compile. -- Joseph
Re: [gentoo-user] compile large packages outside /var/tmp/portage/
On Sun, 14 Apr 2013 12:33:50 -0600, Joseph wrote: How to configure portage not to compile large packages (eg. firefox, thunderbird etc) in /var/tmp/portage/ (RAM disk)? I have only assign 4GB and these packages need more room to compile. I use these two files % cat /etc/portage/env/disk-tmpdir.conf PORTAGE_TMPDIR=/mnt/scratch % cat /etc/portage/package.env/libreoffice app-office/libreoffice disk-tmpdir.conf /mnt/scratch is a dumping ground partition with enough space to keep LO happy, use wherever you want. -- Neil Bothwick God is real, unless specifically declared integer. signature.asc Description: PGP signature
Re: [gentoo-user] compile large packages outside /var/tmp/portage/
On 04/14/13 14:36, yegle wrote: PORTAGE_TMPDIR=/tmp/ying/portage_tmpdir BUILD_PREFIX=/tmp/ying/build_prefix DISTDIR=/tmp/ying/distdir PORTDIR=/tmp/ying/portdir These are the configurations in my make.conf. Details can be found in make.conf(5). -- yegle [1]http://about.me/yegle On my system I have in make.conf PORTAGE_TMPFS=/dev/shm and in fstab: shm /dev/shmdevtmpfsnodev,nosuid,noexec 0 0 tmpfs /var/tmp/portagetmpfs defaults 0 0 which uses half of my ram for compiling packages. So 4GB is OK for most of them except the big ones. -- Joseph
Re: [gentoo-user] compile large packages outside /var/tmp/portage/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14/04/13 20:39, Joseph wrote: On 04/14/13 14:36, yegle wrote: PORTAGE_TMPDIR=/tmp/ying/portage_tmpdir BUILD_PREFIX=/tmp/ying/build_prefix DISTDIR=/tmp/ying/distdir PORTDIR=/tmp/ying/portdir These are the configurations in my make.conf. Details can be found in make.conf(5). -- yegle [1]http://about.me/yegle On my system I have in make.conf PORTAGE_TMPFS=/dev/shm and in fstab: shm /dev/shmdevtmpfs nodev,nosuid,noexec 0 0 tmpfs /var/tmp/portagetmpfs defaults 0 0 which uses half of my ram for compiling packages. So 4GB is OK for most of them except the big ones. You could just read [1]: it tells you have to exclude packages on case-to-case basis as well as telling you some of the main space offenders. [1] - http://en.gentoo-wiki.com/wiki/Portage_TMPDIR_on_tmpfs - -- Mateusz K. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRawZlAAoJEM1mucMq2pqXSJYQAKImAMYGAzzCtq8yxlejTkUl 8pVCbH2cgpMg5EVtge8IOIIL9ApLHe7GiSHb7cpNC2jMomFhcOGqfn7/FZgMxfsD pwlHfw0iHmdaslgtPMck4D4bErZAmTGNuojKZOd4ytRx8GQKPHoKel0lnw0RFxRC JNEqx0Pvp4j61yNnAJZ5N2rAOIU+9o2h4ArMmo/XAaeg60PtsZ48ByU4WgNdqjkl KPyHHFZ2mKovs/IH4q1LWp7erAbCt0DUn1+dfeOZLDKLSPoICviTvWeGrLfPW+fI jTxvfnnd/Ydb1iMChEAcBkT1Tvg5sYM2CJnO8iflIYVpq9tl+UC0lwkT9El2vSmj w2f0ATZ//87QUKxGOUzj/bUJwAhGVk4r5Z9R8DgeTOHHBcNCNRhsLh2r/4q/oGCC nzRthrZFc/3SV0EMTSBY3R6nszR4tZjB5jkvKrPmutIgBY22VskPe7ISIWKslr+k gbILe39ackPCXIq4kE6YyphXG2SKDRzybpDE0xaDv4xTSjURpfCZ66np0Agxl7be ORccEVZifhy/xAX3R50T5/mv4cvI+njdS0QxY4K6fBorCsBLT6OY9FksWg6GohmK aRo+bNAHpI1N46m62YvhPP+E/SYF/ETqGQNT5v6shtYndDxZdjZoLRPw4HASKy72 9ys2Fg8zkp8/GaGlRkGs =CZsp -END PGP SIGNATURE-
