From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Emanuel Berg Newsgroups: gmane.emacs.help Subject: Re: HOWTO: lightning fast Emacs on Linux multicore Date: Sun, 16 Nov 2014 22:04:10 +0100 Organization: Aioe.org NNTP Server Message-ID: <87sihin9h1.fsf@debian.uxu> References: <871tpdl29g.fsf@debian.uxu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1416171927 15322 80.91.229.3 (16 Nov 2014 21:05:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 16 Nov 2014 21:05:27 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sun Nov 16 22:05:22 2014 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xq70b-0002oF-Ud for geh-help-gnu-emacs@m.gmane.org; Sun, 16 Nov 2014 22:05:22 +0100 Original-Received: from localhost ([::1]:45077 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xq70b-0007gR-FN for geh-help-gnu-emacs@m.gmane.org; Sun, 16 Nov 2014 16:05:21 -0500 Original-Path: usenet.stanford.edu!goblin2!goblin.stu.neva.ru!aioe.org!.POSTED!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 147 Original-NNTP-Posting-Host: feB02bRejf23rfBm51Mt7Q.user.speranza.aioe.org Original-X-Complaints-To: abuse@aioe.org User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) X-Notice: Filtered by postfilter v. 0.8.2 Cancel-Lock: sha1:es4ziIXuT7J54Aq9qGxP2zx9pBw= Mail-Copies-To: never Original-Xref: usenet.stanford.edu gnu.emacs.help:208691 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:100969 Archived-At: Bob Proulx writes: >> After rebooting >> >> ps -eo psr,comm | grep ' 1 ' >> >> to see that almost no processes are executing on CPU >> 1. But life in the vault is about to change... > > It seems strange to me that you would not see > processes on both cpus during normal operation. Yes, very strange indeed :) This is what you are expected to get *after* appling the Grub setting. Right now, that command gives me this list - apart from what I explicity allocated CPU 1 with taskset(1) - the following processes on CPU ("psr") 1: 1 watchdog/1 1 migration/1 1 ksoftirqd/1 1 kworker/1:0H 1 kworker/1:1H 1 kworker/1:2 1 kworker/1:1 1 kworker/1:0 Without the Grub setting, I get all sorts of processes on CPU 1 as well as CPU 2. > The kernel will schedule processes on the cpus in > order to optimize performance or other things. Yes, but the kernel strives for maximal *overall* performance. This approach is getting special treatment for Emacs, optimizing the common case. Another way to do it might to change the priority of the Emacs. -20 is the highest priority, and the default priority is 0. So: sudo renice -20 -p `pgrep emacs` Verify with: ps -lC "emacs" And check the NI column (NI for "nice"). > A tool I like a lot for visualizing this is the bar > graphs in 'htop'. You might try it. I expect you > will see that during normal operation all cpus are > going to get processes. Yes, htop(1) is great, only the colors (light cyan and green) I don't like. Here is a screenshot of htop and top(1) together: http://user.it.uu.se/~embe8573/dumps/tops.png Can you see anything interesting? > You didn't say what type of cpu you have but let me > say a word about Intel Hyper-Threading > (https://en.wikipedia.org/wiki/Hyper-threading) in > case it is one of those. HT is a marketing > breakthrough because it is trademarked by Intel and > therefore unavailable on AMD. Previously when I > benchmarked performance I found that HT helped a > single core by a very small amount but that it > degraded multi-core again by a very small amount. > Therefore I recommend disabling HT on multi-core > systems. > > If you have an HT system and it is enabled then a > dual core cpu will be displayed as a quad-core. That > will be two cores with two threads per core. It is > very easy to misinterpret this as four symetric > cores. It is very easy to misinterpret the kernel > scheduling algorithm as not using a core when in > reality it is simply scheduling efficiently around > the threads. Because cpu0 and cpu1 are two threads > on the same core and cpu2 and cpu3 are two threads > on the same core. A task running on cpu0 consumes > both cpu0 and cpu1. If the kernel scheduled a task > on both cpu0 and cpu1 while cpu2 or cpu3 are idle > then the tasks sharing the first core would run at > half speed. > > I mention this because hyper-threading is very easy > to misdiagnose. In the early days back in the Linux > 2.4 kernel it knew nothing of cpu threads and would > do exactly this and HT needed to be disabled. That was a lot to digest :) I'll read that Wikipedia article later and see if that clarifies things. My CPU is, according to lscpu(1): Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 2 On-line CPU(s) list: 0,1 Thread(s) per core: 1 Core(s) per socket: 2 Socket(s): 1 NUMA node(s): 1 Vendor ID: AuthenticAMD CPU family: 15 Model: 35 Model name: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ Stepping: 2 CPU MHz: 1000.000 CPU max MHz: 2000.0000 CPU min MHz: 1000.0000 BogoMIPS: 1989.83 L1d cache: 64K L1i cache: 64K L2 cache: 512K NUMA node0 CPU(s): 0,1 > One moment I am editing. Another moment email is > being transfered. Another moment I am browsing the > web. Another moment it is updating the system clock. > Another moment it is running a cron task. Another > moment reading and writing files to disk. Another > moment it is generating entropy for an https or ssh > encryption process. Another moment it is updating > the display. These are all things that are all being > mixed together. Indeed, thats how it works in general. However, I do web browsing, mail, Usenet, all programming including compilation, actually I do everything in Emacs by now. So I think it makes sense for the system to not strive for general performance, but for special-treatment of the number one process. Anyway that's the reasoning behind this method, if it holds, let's just say it is complicated and difficult to quantify. It feels faster is all I know for sure. -- underground experts united