From owner-freebsd-hackers@freebsd.org Fri Feb 22 11:20:16 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4795414E6DFD for ; Fri, 22 Feb 2019 11:20:16 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 367BC8F4B4 for ; Fri, 22 Feb 2019 11:20:12 +0000 (UTC) (envelope-from pieter@degoeje.nl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1550834410; s=strato-dkim-0002; d=degoeje.nl; h=In-Reply-To:Date:Message-ID:From:References:To:Subject: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=yiTj9JsA/thfD2ERLx20+mF1YzSTgfmRNPKsQpXiP8E=; b=dRvVAK4+7z7eZcZPFArQ/BbW5/RARXia2JtTFWN6Upzr6eSU3y/PWRv2vbDWe6V8Bu I2Gnralb3JVssEtAMgUDCu1iNPWPFQRsXwfxQqaBcNLkxIa5v5x5+n0/+S5hxsMIgs1j JR/8qodmU+XY4ognUeAw2u95wvTw5M/n/c31Idc92PElzX/7Pp1R98iqvOR869xGZvF+ FCbxrQlROW4VTXQjYMjDkTBSDeqel+eXGHz/jyJsYo7rgePfSXQ7L/u+eAyL0mdweySY latR8XLbsV4z+rJ7Bw6BiuePNkDdyhFlkwjhRu4CN5UOeJqllCG5GLLjkbVL5JZzUvdV uwYg== X-RZG-AUTH: ":PGUBYUW6W/vjKUwSpXdHbXp/KlnzhfjpGaq9ccFSB01ZbYSz0XXyHEnBMb8k5m4K" X-RZG-CLASS-ID: mo00 Received: from [192.168.1.108] by smtp.strato.com (RZmta 44.9 AUTH) with ESMTPSA id 202019v1MBJZp0W (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Fri, 22 Feb 2019 12:19:35 +0100 (CET) Subject: Re: Optimize execution of processes by CPU core To: Eugene Grosbein , Farhan Khan , freebsd-hackers@freebsd.org References: <2fcd9aee092730e11880c3ae88de4898@farhan.codes> From: Pieter de Goeje Message-ID: <7ff616b5-03c5-7650-d28b-6e85e8aa5f0e@degoeje.nl> Date: Fri, 22 Feb 2019 12:19:35 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: nl Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 367BC8F4B4 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=degoeje.nl header.s=strato-dkim-0002 header.b=dRvVAK4+ X-Spamd-Result: default: False [-3.78 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[degoeje.nl:s=strato-dkim-0002]; RCVD_IN_DNSWL_LOW(-0.10)[5.0.0.0.0.0.0.0.0.0.0.0.0.0.3.5.2.0.2.0.a.0.2.0.8.3.2.0.1.0.a.2.list.dnswl.org : 127.0.5.1]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[degoeje.nl]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[smtp.rzone.de]; DKIM_TRACE(0.00)[degoeje.nl:+]; NEURAL_HAM_SHORT(-0.50)[-0.504,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-0.86)[ipnet: 2a01:238::/32(-3.67), asn: 6724(-0.64), country: DE(-0.01)]; ASN(0.00)[asn:6724, ipnet:2a01:238::/32, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2019 11:20:16 -0000 Op 20-2-2019 om 19:19 schreef Eugene Grosbein: > 21.02.2019 0:35, Farhan Khan via freebsd-hackers wrote: >> Hi all, >> >> I am trying to optimize the execution of a CPU-intensive workload where I am running multiple instances of a program. >> The moment the program ends (expected behavior), the calling shell script verifies the results and if its good it reruns the program. >> The machines I am running this on have 8 cores, but ps reports that some of the processes frequently run on the same CPU, >> so I suspect I am not getting optimized performance. > > System scheduler switches useland processed from one CPU core to another often enough > so each CPU has even load and you cannot see that with naked. But you can easily verify > if load is even or not checking sysctl kern.cp_times that shows five monotonically increasing > counters per each CPU core. For example, in case of dual-core system: > > $ sysctl kern.cp_times > kern.cp_times: 14789486 132229 14016113 327160 949428773 14374865 139326 12056998 2941012 949179638 > $ sysctl kern.clockrate > kern.clockrate: { hz = 1000, tick = 1000, profhz = 8126, stathz = 127 } > > There are "stathz" ticks per second and for each core exactly one of five counters is incremented by one: > user, nice, system, interrupt, idle. That is, each 5th counter is incremented > if corresponding CPU core was idle during "the tick". > > You can save output of sysctl kern.cp_times, run your test, stop it and save output again. > Then compare difference of each 5th counter and they should be approximately equal. > > You can even draw graphs if you periodically get samples of the sysctl, compute diffs with previous samples, > divide diffs by period length in seconds and then divide again by "stathz" value. > Multiply by 100 to get idle time of single CPU code in percents for the period. > Repeat for each core. > > I use net-mgmt/mrtg to draw such per-CPU graphs for my servers, it works just fine. `top -P` does the same thing. It displays a user/nice/system/interrupt/idle line for each CPU. - Pieter