From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 86725EB64DD for ; Thu, 20 Jul 2023 13:00:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B7CDC2800FE; Thu, 20 Jul 2023 09:00:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B2CB62800FF; Thu, 20 Jul 2023 09:00:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9CD282800FE; Thu, 20 Jul 2023 09:00:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 8B31428004C for ; Thu, 20 Jul 2023 09:00:15 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 1FB37120173 for ; Thu, 20 Jul 2023 13:00:15 +0000 (UTC) X-FDA: 81031998390.18.68A4247 Received: from mail-vk1-f179.google.com (mail-vk1-f179.google.com [209.85.221.179]) by imf24.hostedemail.com (Postfix) with ESMTP id D834D18000B for ; Thu, 20 Jul 2023 13:00:08 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=XzNSdn3G; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf24.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.221.179 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1689858008; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=mLa6UJOWW/B5cmDVeDgwxqaFOtsq36f9MM8GBuRmH28=; b=g77ej8TVB/NmsYaxgJ6QB45hfBNl6mIqFG3GpRw6KpOgR3E6p0qztfacFoq98Pwm07fAzw +ioRNBrLENyeyU2uhJqxbWb0j0a3ZMHODH3lRLFt/DmUbpRQa9zRE9Pu0cVwT/GYUik7ue k708bhCl5Hg8rC6eMz6p89SH6L9WcE0= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=XzNSdn3G; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf24.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.221.179 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1689858008; a=rsa-sha256; cv=none; b=eT0QprS1oKWM7kyLWvrnPuXkUC9poWw8feWWF5TdxIpSfQcSseiWLukkZzvyrhQht4zMwD GpNoXDB6whjaUlVl+boP8Hpm4afU6zn/PjAbG6Cbr5WtAtClvswObqR0m5p449+9R1bYYZ GLbflnPdTMB6/iQJ9wl+NT3mIrgHYvY= Received: by mail-vk1-f179.google.com with SMTP id 71dfb90a1353d-4814505ddbbso348400e0c.0 for ; Thu, 20 Jul 2023 06:00:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689858007; x=1690462807; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=mLa6UJOWW/B5cmDVeDgwxqaFOtsq36f9MM8GBuRmH28=; b=XzNSdn3GAKVQHwg4qp95v/8PAAO4Q0KPvYIiFMlG2zBx7/38j8xuWwW1AQGpyik7wP iAKQrOMb06tvxQfN7GVkAMwzOqxiHHE7rKPneJ+hgRRSq5sTBECqf7Zlx+P+GLrxndzf 2uYEbJMwWfbQApq8ihsRQjcLAYiWRplFEfmR+vVFZ7DVGPg2w5AtoBZSG5ZOwPP+iQTo BqrpLr/pqcAj2vaXjZ0COwstZ5LwvtsjdK44XWG18TDuMItSLkygVNHwJdFhenmkXoY6 h2n5R2rRICfxYpyPxKaPgbIhhNXaatz+MnR9s038yp6FE2EkBQ9cwP3jvGzMqXVJn+/g IhBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689858007; x=1690462807; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=mLa6UJOWW/B5cmDVeDgwxqaFOtsq36f9MM8GBuRmH28=; b=fY7he7cCAdmAh6LG3CV0a9tJe9giMedObK7VZYZrM35jsEUkpp9w/46uZZ9clfubNE UJIcrCcyRA7sejii9a8On35tpo8hDwIvLYIkRB+o8zmxYwkcih0eru3L86tPuB239XyH yhAZfPk9/8c3s1sXPEGI/PDGXcbMlUhdtEWqh3/5hrRZZ+omBuHoXYXdqmhdh2fWubGX I7eZEpbqSuEO6ehZhc99nQ3gidhMQCAIrCMVflNHuy/4Kr/V6gKfu7HqWCTRerypXZki BgUknH9GINQPlQx8+2DFfhNSjK4bskByCIjiGEAwAjyYDcxXoG++6DSgy0dlza7ziZu7 FfqQ== X-Gm-Message-State: ABy/qLYmz8prBFxqcftPPvsppHHE5kJzjRBUXEfA4vligAkVS6vnmdcv y2R/3AjfMMRnhKSvKYORGo6vZoHQ9V5lZVuCEjk= X-Google-Smtp-Source: APBJJlGegfkJhYJtei9Ttbs2Tj2ASlCADIjVxkHC5Plh2H8vE5SqfWSAuZJNLfJyu8jNbR0IqHELw3CtYB4oiwA1000= X-Received: by 2002:a1f:3d44:0:b0:465:fa30:d633 with SMTP id k65-20020a1f3d44000000b00465fa30d633mr3905764vka.0.1689858007282; Thu, 20 Jul 2023 06:00:07 -0700 (PDT) MIME-Version: 1.0 References: <20230628095740.589893-1-jaypatel@linux.ibm.com> <202307172140.3b34825a-oliver.sang@intel.com> In-Reply-To: From: Hyeonggon Yoo <42.hyeyoo@gmail.com> Date: Thu, 20 Jul 2023 21:59:56 +0900 Message-ID: Subject: Re: [PATCH] [RFC PATCH v2]mm/slub: Optimize slub memory usage To: Oliver Sang Cc: Jay Patel , oe-lkp@lists.linux.dev, lkp@intel.com, linux-mm@kvack.org, ying.huang@intel.com, feng.tang@intel.com, fengwei.yin@intel.com, cl@linux.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, vbabka@suse.cz, aneesh.kumar@linux.ibm.com, tsahu@linux.ibm.com, piyushs@linux.ibm.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: D834D18000B X-Stat-Signature: 1h45asd9npt4fczqwzwm8ygadma5anyf X-HE-Tag: 1689858008-641620 X-HE-Meta: U2FsdGVkX18GlZRfQsaxO1hmw5NIv4hGRLOtCt38NbRs3wx6xWAPrJeOAsmDFwrF8ZgZWmKGDd1f7Ts7UbHuNLUCoAeE8RTaWvJUSTD8w26WciYaiJGCdemhU8sxi3mXy04ELrN1AEHXjSbw4StwF4aBPoYN4iwS87yT62msQ+CH/HRU8/5LEcfR+m8Y+mYT9DFkF6OgxhpRcn07Gob/r1GU59c1sh4S5z8gSnxYBfp/5vaiXfcSB5+25XhSaLyLD4uMvA4mAGhVo2wCuh3jsf2I4pwXw0+YBX/bUWYBaGB+/JZhOTIAv6kKOA3O1Jg0OQdlz2hmvFmWau8G1P58Z6vg/alBjMX8ty4vUnoBjf5Lt2UyVdE5jbBcvWEHdDJ2HdMlBHJfoKBqfkVUBL7lg6pcYYURZNLG4trSxrUHW7vC/Yrr5T6CCEyVKQ6fmxJ6YqtGXFm3YEVCKAea+OYu6oBW0SQUgaoll4LjWB9O5HXhjwtXCL72Q2A8mhZ8BrIvC/vXENBIdyg1k57/mrhXyKDR62h4d+tMCWxTnQzLqEKSaoiYJyWO06LexxCAiqkFYTnuVCdWx/X4zYGKZ+kMIySTyCmqIJzJp0HuywwvWAXtAycka07t1IvhGNNe8arzb68MKImsz7uEuMUm3yM4/DyzagiyAnXYuxNA1vQyrk9kb3g+skPOrWExEKS7aNsDmioh7fKXAIdGPLaQjwqFyW/6yckxJQsvQB1rJ3K+voHkqCZP4axnlaEkD1qja791mV6vC2buo+9LjMH88QIxrGCogzi9/PaBDG55F5iXdnVb87d7JkmbGCri+VgkkPut0kGXIRoO8ZDv1xizyMDRLVRLDTP2nOex0KX0AAazIvNf81c8F1GFUwB5Zx31Krno/2YVO2a3oGi3wd8tZA0k0kxENruJZyp5AB9N7r3NeFQRv74KM9H6U17nNpACxWcjJUR8xZVOFeUrw/NQ5/c c2Mz8f8n p0GFgtaBkByEqRsfVbtnJovvZY94OaDif2e6up/i4z5vkUyCDdFw6DGbdKiI/L/932CVLZOlgdmyhlCzAnCpQVRtRNJJE1gzvhZBfTkHzdlZTLSCYuHus3FGO2xYObEjkIbo3soNAWXPnA5HP5lAySbDGje2BRohgmzIFzfMjc9ZO7JOK8se7AeY9HzPFWaSKuo7yRdn1ZoaKS3yq2PPPXBfFufZ+YUiGLdkKU+9NM9qdboVo0PUxJRqSWsCQIFQZtf4RrV9fv0JWCCWsDln7fKPEY08Eg5fkJGoFB47+tYLtVuh0SNTJpsn+C+ZEXWzzDicdiV9ruG72dyJhJyPp3Qs5+2Cm8ZT3v5cxVzA0JWnHUIb5JFXvSWcQ2L2WdrYjQIV97qZGj6VuHHU7uWs5Cldc8RAOa/6cSxacjm3cCNZrWuOnszyqHCKKAC9mfq0wNwh3PZsZ4mBA3N/TsQLI89Np984KP7/i/Hb0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Jul 20, 2023 at 12:01=E2=80=AFPM Oliver Sang wrote: > > hi, Hyeonggon Yoo, > > On Tue, Jul 18, 2023 at 03:43:16PM +0900, Hyeonggon Yoo wrote: > > On Mon, Jul 17, 2023 at 10:41=E2=80=AFPM kernel test robot > > wrote: > > > > > > > > > > > > Hello, > > > > > > kernel test robot noticed a -12.5% regression of hackbench.throughput= on: > > > > > > > > > commit: a0fd217e6d6fbd23e91f8796787b621e7d576088 ("[PATCH] [RFC PATCH= v2]mm/slub: Optimize slub memory usage") > > > url: https://github.com/intel-lab-lkp/linux/commits/Jay-Patel/mm-slub= -Optimize-slub-memory-usage/20230628-180050 > > > base: git://git.kernel.org/cgit/linux/kernel/git/vbabka/slab.git for-= next > > > patch link: https://lore.kernel.org/all/20230628095740.589893-1-jaypa= tel@linux.ibm.com/ > > > patch subject: [PATCH] [RFC PATCH v2]mm/slub: Optimize slub memory us= age > > > > > > testcase: hackbench > > > test machine: 128 threads 2 sockets Intel(R) Xeon(R) Gold 6338 CPU @ = 2.00GHz (Ice Lake) with 256G memory > > > parameters: > > > > > > nr_threads: 100% > > > iterations: 4 > > > mode: process > > > ipc: socket > > > cpufreq_governor: performance > > > > > > > > > > > > > > > If you fix the issue in a separate patch/commit (i.e. not just a new = version of > > > the same patch/commit), kindly add following tags > > > | Reported-by: kernel test robot > > > | Closes: https://lore.kernel.org/oe-lkp/202307172140.3b34825a-oliver= .sang@intel.com > > > > > > > > > Details are as below: > > > ---------------------------------------------------------------------= -----------------------------> > > > > > > > > > To reproduce: > > > > > > git clone https://github.com/intel/lkp-tests.git > > > cd lkp-tests > > > sudo bin/lkp install job.yaml # job file is attache= d in this email > > > bin/lkp split-job --compatible job.yaml # generate the yaml f= ile for lkp run > > > sudo bin/lkp run generated-yaml-file > > > > > > # if come across any failure that blocks the test, > > > # please remove ~/.lkp and /lkp dir to run from a clean state= . > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > compiler/cpufreq_governor/ipc/iterations/kconfig/mode/nr_threads/root= fs/tbox_group/testcase: > > > gcc-12/performance/socket/4/x86_64-rhel-8.3/process/100%/debian-11.= 1-x86_64-20220510.cgz/lkp-icl-2sp2/hackbench > > > > > > commit: > > > 7bc162d5cc ("Merge branches 'slab/for-6.5/prandom', 'slab/for-6.5/s= lab_no_merge' and 'slab/for-6.5/slab-deprecate' into slab/for-next") > > > a0fd217e6d ("mm/slub: Optimize slub memory usage") > > > > > > 7bc162d5cc4de5c3 a0fd217e6d6fbd23e91f8796787 > > > ---------------- --------------------------- > > > %stddev %change %stddev > > > \ | \ > > > 222503 =C4=85 86% +108.7% 464342 =C4=85 58% numa-meminfo.= node1.Active > > > 222459 =C4=85 86% +108.7% 464294 =C4=85 58% numa-meminfo.= node1.Active(anon) > > > 55573 =C4=85 85% +108.0% 115619 =C4=85 58% numa-vmstat.n= ode1.nr_active_anon > > > 55573 =C4=85 85% +108.0% 115618 =C4=85 58% numa-vmstat.n= ode1.nr_zone_active_anon > > > > I'm quite baffled while reading this. > > How did changing slab order calculation double the number of active ano= n pages? > > I doubt two experiments were performed on the same settings. > > let me introduce our test process. > > we make sure the tests upon commit and its parent have exact same environ= ment > except the kernel difference, and we also make sure the config to build t= he > commit and its parent are identical. > > we run tests for one commit at least 6 times to make sure the data is sta= ble. > > such like for this case, we rebuild the commit and its parent's kernel, t= he > config is attached FYI. Hello Oliver, Thank you for confirming the testing environment is totally fine. and I'm sorry. I didn't mean to offend that your tests were bad. It was more like "oh, the data totally doesn't make sense to me" and I blamed the tests rather than my poor understanding of the data ;) Anyway, as the data shows a repeatable regression, let's think more about the possible scenario: I can't stop thinking that the patch must've affected the system's reclamation behavior in some way. (I think more active anon pages with a similar number total of anon pages implies the kernel scanned more pages) It might be because kswapd was more frequently woken up (possible if skbs were allocated with GFP_ATOMIC) But the data provided is not enough to support this argument. > 2.43 =C2=B1 7% +4.5 6.90 =C2=B1 11% perf-profile.children.cycles-pp.get_= partial_node > 3.23 =C2=B1 5% +4.5 7.77 =C2=B1 9% perf-profile.children.= cycles-pp.___slab_alloc > 7.51 =C2=B1 2% +4.6 12.11 =C2=B1 5% perf-profile.children.= cycles-pp.kmalloc_reserve > 6.94 =C2=B1 2% +4.7 11.62 =C2=B1 6% perf-profile.children.c= ycles-pp.__kmalloc_node_track_caller > 6.46 =C2=B1 2% +4.8 11.22 =C2=B1 6% perf-profile.children.c= ycles-pp.__kmem_cache_alloc_node > 8.48 =C2=B1 4% +7.9 16.42 =C2=B1 8% perf-profile.children.= cycles-pp._raw_spin_lock_irqsave > 6.12 =C2=B1 6% +8.6 14.74 =C2=B1 9% perf-profile.children.= cycles-pp.native_queued_spin_lock_slowpath And this increased cycles in the SLUB slowpath implies that the actual number of objects available in the per cpu partial list has been decreased, possibly because of inaccuracy in the heuristic? (cuz the assumption that slabs cached per are half-filled, and that slabs' order is s->oo) Any thoughts, Vlastimil or Jay? > > then retest on this test machine: > 128 threads 2 sockets Intel(R) Xeon(R) Gold 6338 CPU @ 2.00GHz (Ice Lake)= with 256G memory > > we noticed the regression still exists (datail comparison is attached > as hackbench-a0fd217e6d-ICL-Gold-6338): > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > compiler/cpufreq_governor/ipc/iterations/kconfig/mode/nr_threads/rootfs/t= box_group/testcase: > gcc-12/performance/socket/4/x86_64-rhel-8.3/process/100%/debian-11.1-x8= 6_64-20220510.cgz/lkp-icl-2sp2/hackbench > > 7bc162d5cc4de5c3 a0fd217e6d6fbd23e91f8796787 > ---------------- --------------------------- > %stddev %change %stddev > \ | \ > 479042 -12.5% 419357 hackbench.throughput > > the real data is as below, > > for 7bc162d5cc: > "hackbench.throughput": [ > 480199.7631014502, > 478713.21886768367, > 480692.1967633392, > 476795.9313413859, > 478545.2225235285, > 479309.7938967886 > ], > > for a0fd217e6d: > "hackbench.throughput": [ > 422654.2688081149, > 419017.82222470525, > 416817.183983105, > 423286.39557524625, > 414307.41610274825, > 420062.1692010417 > ], > > > we also rerun the tests on another test machine: > 128 threads 2 sockets Intel(R) Xeon(R) Platinum 8358 CPU @ 2.60GHz (Ice L= ake) with 128G memory > > still found a regression > (detail as attached hackbench-a0fd217e6d-ICL-Platinum-8358): > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > compiler/cpufreq_governor/ipc/iterations/kconfig/mode/nr_threads/rootfs/t= box_group/testcase: > gcc-12/performance/socket/4/x86_64-rhel-8.3/process/100%/debian-11.1-x8= 6_64-20220510.cgz/lkp-icl-2sp6/hackbench > > 7bc162d5cc4de5c3 a0fd217e6d6fbd23e91f8796787 > ---------------- --------------------------- > %stddev %change %stddev > \ | \ > 455347 -5.9% 428458 hackbench.throughput > > > > > > > 1377834 =C4=85 2% -10.7% 1230013 sched_debug.cpu.nr= _switches.avg > > > 1218144 =C4=85 2% -13.3% 1055659 =C4=85 2% sched_debug.c= pu.nr_switches.min > > > 3047631 =C4=85 2% -13.2% 2646560 vmstat.system.cs > > > 561797 -13.8% 484137 vmstat.system.in > > > 280976 =C4=85 66% +122.6% 625459 =C4=85 52% meminfo.Activ= e > > > 280881 =C4=85 66% +122.6% 625365 =C4=85 52% meminfo.Activ= e(anon) > > > 743351 =C4=85 4% -9.7% 671534 =C4=85 6% meminfo.AnonP= ages > > > 1.36 -0.1 1.21 mpstat.cpu.all.irq% > > > 0.04 =C4=85 4% -0.0 0.03 =C4=85 4% mpstat.cpu.al= l.soft% > > > 5.38 -0.8 4.58 mpstat.cpu.all.usr% > > > 0.26 -11.9% 0.23 turbostat.IPC > > > 160.93 -19.3 141.61 turbostat.PKG_% > > > 60.48 -8.9% 55.10 turbostat.RAMWatt > > > 70049 =C4=85 68% +124.5% 157279 =C4=85 52% proc-vmstat.n= r_active_anon > > > 185963 =C4=85 4% -9.8% 167802 =C4=85 6% proc-vmstat.n= r_anon_pages > > > 37302 -1.2% 36837 proc-vmstat.nr_slab_rec= laimable > > > 70049 =C4=85 68% +124.5% 157279 =C4=85 52% proc-vmstat.n= r_zone_active_anon > > > 1101451 +12.0% 1233638 proc-vmstat.unevictable= _pgs_scanned > > > 477310 -12.5% 417480 hackbench.throughput > > > 464064 -12.0% 408333 hackbench.throughput_av= g > > > 477310 -12.5% 417480 hackbench.throughput_be= st > > > 435294 -9.5% 394098 hackbench.throughput_wo= rst > > > 131.28 +13.4% 148.89 hackbench.time.elapsed_= time > > > 131.28 +13.4% 148.89 hackbench.time.elapsed_= time.max > > > 90404617 -5.2% 85662614 =C4=85 2% hackbench.time.inv= oluntary_context_switches > > > 15342 +15.0% 17642 hackbench.time.system_t= ime > > > 866.32 -3.2% 838.32 hackbench.time.user_tim= e > > > 4.581e+10 -11.2% 4.069e+10 perf-stat.i.branch-inst= ructions > > > 0.45 +0.1 0.56 perf-stat.i.branch-miss= -rate% > > > 2.024e+08 +11.8% 2.263e+08 perf-stat.i.branch-miss= es > > > 21.49 -1.1 20.42 perf-stat.i.cache-miss-= rate% > > > 4.202e+08 -16.6% 3.505e+08 perf-stat.i.cache-misse= s > > > 1.935e+09 -11.5% 1.711e+09 perf-stat.i.cache-refer= ences > > > 3115707 =C4=85 2% -13.9% 2681887 perf-stat.i.contex= t-switches > > > 1.31 +13.2% 1.48 perf-stat.i.cpi > > > 375155 =C4=85 3% -16.3% 314001 =C4=85 2% perf-stat.i.c= pu-migrations > > > 6.727e+10 -11.2% 5.972e+10 perf-stat.i.dTLB-loads > > > 4.169e+10 -12.2% 3.661e+10 perf-stat.i.dTLB-stores > > > 2.465e+11 -11.4% 2.185e+11 perf-stat.i.instruction= s > > > 0.77 -11.8% 0.68 perf-stat.i.ipc > > > 818.18 =C4=85 5% +61.8% 1323 =C4=85 2% perf-stat.i.m= etric.K/sec > > > 1225 -11.6% 1083 perf-stat.i.metric.M/se= c > > > 11341 =C4=85 4% -12.6% 9916 =C4=85 4% perf-stat.i.m= inor-faults > > > 1.27e+08 -13.2% 1.102e+08 perf-stat.i.node-load-m= isses > > > 3376198 -15.4% 2855906 perf-stat.i.node-loads > > > 72756698 -22.9% 56082330 perf-stat.i.node-store-= misses > > > 4118986 =C4=85 2% -19.3% 3322276 perf-stat.i.node-s= tores > > > 11432 =C4=85 3% -12.6% 9991 =C4=85 4% perf-stat.i.p= age-faults > > > 0.44 +0.1 0.56 perf-stat.overall.branc= h-miss-rate% > > > 21.76 -1.3 20.49 perf-stat.overall.cache= -miss-rate% > > > 1.29 +13.5% 1.47 perf-stat.overall.cpi > > > 755.39 +21.1% 914.82 perf-stat.overall.cycle= s-between-cache-misses > > > 0.77 -11.9% 0.68 perf-stat.overall.ipc > > > 4.546e+10 -11.0% 4.046e+10 perf-stat.ps.branch-ins= tructions > > > 2.006e+08 +12.0% 2.246e+08 perf-stat.ps.branch-mis= ses > > > 4.183e+08 -16.8% 3.48e+08 perf-stat.ps.cache-miss= es > > > 1.923e+09 -11.7% 1.699e+09 perf-stat.ps.cache-refe= rences > > > 3073921 =C4=85 2% -13.9% 2647497 perf-stat.ps.conte= xt-switches > > > 367849 =C4=85 3% -16.1% 308496 =C4=85 2% perf-stat.ps.= cpu-migrations > > > 6.683e+10 -11.2% 5.938e+10 perf-stat.ps.dTLB-loads > > > 4.144e+10 -12.2% 3.639e+10 perf-stat.ps.dTLB-store= s > > > 2.447e+11 -11.2% 2.172e+11 perf-stat.ps.instructio= ns > > > 10654 =C4=85 4% -11.5% 9428 =C4=85 4% perf-stat.ps.= minor-faults > > > 1.266e+08 -13.5% 1.095e+08 perf-stat.ps.node-load-= misses > > > 3361116 -15.6% 2836863 perf-stat.ps.node-loads > > > 72294146 -23.1% 55573600 perf-stat.ps.node-store= -misses > > > 4043240 =C4=85 2% -19.4% 3258771 perf-stat.ps.node-= stores > > > 10734 =C4=85 4% -11.6% 9494 =C4=85 4% perf-stat.ps.= page-faults > > > > <...> > > > > > > > > Disclaimer: > > > Results have been estimated based on internal Intel analysis and are = provided > > > for informational purposes only. Any difference in system hardware or= software > > > design or configuration may affect actual performance. > > > > > > > > > -- > > > 0-DAY CI Kernel Test Service > > > https://github.com/intel/lkp-tests/wiki > > > > > > > >