Searched hist:13041 (Results 1 - 11 of 11) sorted by relevance

/linux-master/Documentation/devicetree/bindings/mips/brcm/
H A Dsoc.txtdiff 7537d273 Fri Apr 08 16:56:48 MDT 2016 Álvaro Fernández Rojas <noltari@gmail.com> MIPS: BMIPS: Add device tree example for BCM6358

This adds a device tree example for SFR Neufbox4 (Sercomm version), which
also serves as a real example for brcm,bcm6358-leds.

Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
Cc: f.fainelli@gmail.com
Cc: jogo@openwrt.org
Cc: cernekee@gmail.com
Cc: robh@kernel.org
Cc: simon@fire.lp0.eu
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Cc: devicetree@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/13041/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
/linux-master/arch/mips/bmips/
H A DKconfigdiff 7537d273 Fri Apr 08 16:56:48 MDT 2016 Álvaro Fernández Rojas <noltari@gmail.com> MIPS: BMIPS: Add device tree example for BCM6358

This adds a device tree example for SFR Neufbox4 (Sercomm version), which
also serves as a real example for brcm,bcm6358-leds.

Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
Cc: f.fainelli@gmail.com
Cc: jogo@openwrt.org
Cc: cernekee@gmail.com
Cc: robh@kernel.org
Cc: simon@fire.lp0.eu
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Cc: devicetree@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/13041/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
/linux-master/arch/mips/boot/dts/brcm/
H A Dbcm6358.dtsi7537d273 Fri Apr 08 16:56:48 MDT 2016 Álvaro Fernández Rojas <noltari@gmail.com> MIPS: BMIPS: Add device tree example for BCM6358

This adds a device tree example for SFR Neufbox4 (Sercomm version), which
also serves as a real example for brcm,bcm6358-leds.

Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
Cc: f.fainelli@gmail.com
Cc: jogo@openwrt.org
Cc: cernekee@gmail.com
Cc: robh@kernel.org
Cc: simon@fire.lp0.eu
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Cc: devicetree@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/13041/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
H A DMakefilediff 7537d273 Fri Apr 08 16:56:48 MDT 2016 Álvaro Fernández Rojas <noltari@gmail.com> MIPS: BMIPS: Add device tree example for BCM6358

This adds a device tree example for SFR Neufbox4 (Sercomm version), which
also serves as a real example for brcm,bcm6358-leds.

Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
Cc: f.fainelli@gmail.com
Cc: jogo@openwrt.org
Cc: cernekee@gmail.com
Cc: robh@kernel.org
Cc: simon@fire.lp0.eu
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Cc: devicetree@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/13041/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
/linux-master/scripts/dtc/include-prefixes/mips/brcm/
H A Dbcm6358.dtsi7537d273 Fri Apr 08 16:56:48 MDT 2016 Álvaro Fernández Rojas <noltari@gmail.com> MIPS: BMIPS: Add device tree example for BCM6358

This adds a device tree example for SFR Neufbox4 (Sercomm version), which
also serves as a real example for brcm,bcm6358-leds.

Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
Cc: f.fainelli@gmail.com
Cc: jogo@openwrt.org
Cc: cernekee@gmail.com
Cc: robh@kernel.org
Cc: simon@fire.lp0.eu
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Cc: devicetree@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/13041/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
H A DMakefilediff 7537d273 Fri Apr 08 16:56:48 MDT 2016 Álvaro Fernández Rojas <noltari@gmail.com> MIPS: BMIPS: Add device tree example for BCM6358

This adds a device tree example for SFR Neufbox4 (Sercomm version), which
also serves as a real example for brcm,bcm6358-leds.

Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
Cc: f.fainelli@gmail.com
Cc: jogo@openwrt.org
Cc: cernekee@gmail.com
Cc: robh@kernel.org
Cc: simon@fire.lp0.eu
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Cc: devicetree@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/13041/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
/linux-master/drivers/acpi/acpica/
H A Dhwsleep.cdiff 96f15efc Fri Apr 17 21:32:20 MDT 2009 Len Brown <len.brown@intel.com> ACPI: Disable _GTS and _BFS support by default

Executing BIOS code paths not exercised by Windows
tends to get Linux into trouble.

However, if a system does benefit from _GTS or _BFS,
acpi.gts=1 an acpi.bfs=1 are now available to enable them.

http://bugzilla.kernel.org/show_bug.cgi?id=13041

Signed-off-by: Len Brown <len.brown@intel.com>
H A DMakefilediff 51991763 Thu May 07 13:24:31 MDT 2009 Len Brown <len.brown@intel.com> ACPICA: use acpi.* modparam namespace

Add acpi/acpica/*.c to the acpi.* modparam namespace
so that any modparams we stick into ACPICA do not
expose ACPICA filenames to users.

There are currently only two modparams in ACPICA,
just recently added for
http://bugzilla.kernel.org/show_bug.cgi?id=13041

With this change, they become

acpi.gts=1
acpi.bfs=1

rather than

hwsleep.gts=1
hwsleep.bfs=1

Signed-off-by: Len Brown <len.brown@intel.com>
/linux-master/arch/powerpc/include/asm/
H A Duaccess.hdiff 2f279eeb Tue Aug 11 18:25:17 MDT 2020 Christophe Leroy <christophe.leroy@csgroup.eu> powerpc/uaccess: Add pre-update addressing to __get_user_asm() and __put_user_asm()

Enable pre-update addressing mode in __get_user_asm() and __put_user_asm()

Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/13041c7df39e89ddf574ea0cdc6dedfdd9734140.1597235091.git.christophe.leroy@csgroup.eu
/linux-master/drivers/acpi/
H A Dsleep.cdiff 96f15efc Fri Apr 17 21:32:20 MDT 2009 Len Brown <len.brown@intel.com> ACPI: Disable _GTS and _BFS support by default

Executing BIOS code paths not exercised by Windows
tends to get Linux into trouble.

However, if a system does benefit from _GTS or _BFS,
acpi.gts=1 an acpi.bfs=1 are now available to enable them.

http://bugzilla.kernel.org/show_bug.cgi?id=13041

Signed-off-by: Len Brown <len.brown@intel.com>
/linux-master/mm/
H A Dpage_alloc.cdiff f26b3fa0 Tue Mar 22 15:43:45 MDT 2022 Mel Gorman <mgorman@techsingularity.net> mm/page_alloc: limit number of high-order pages on PCP during bulk free

When a PCP is mostly used for frees then high-order pages can exist on
PCP lists for some time. This is problematic when the allocation
pattern is all allocations from one CPU and all frees from another
resulting in colder pages being used. When bulk freeing pages, limit
the number of high-order pages that are stored on the PCP lists.

Netperf running on localhost exhibits this pattern and while it does not
matter for some machines, it does matter for others with smaller caches
where cache misses cause problems due to reduced page reuse. Pages
freed directly to the buddy list may be reused quickly while still cache
hot where as storing on the PCP lists may be cold by the time
free_pcppages_bulk() is called.

Using perf kmem:mm_page_alloc, the 5 most used page frames were

5.17-rc3
13041 pfn=0x111a30
13081 pfn=0x5814d0
13097 pfn=0x108258
13121 pfn=0x689598
13128 pfn=0x5814d8

5.17-revert-highpcp
192009 pfn=0x54c140
195426 pfn=0x1081d0
200908 pfn=0x61c808
243515 pfn=0xa9dc20
402523 pfn=0x222bb8

5.17-full-series
142693 pfn=0x346208
162227 pfn=0x13bf08
166413 pfn=0x2711e0
166950 pfn=0x2702f8

The spread is wider as there is still time before pages freed to one PCP
get released with a tradeoff between fast reuse and reduced zone lock
acquisition.

On the machine used to gather the traces, the headline performance was
equivalent.

netperf-tcp
5.17.0-rc3 5.17.0-rc3 5.17.0-rc3
vanilla mm-reverthighpcp-v1r1 mm-highpcplimit-v2
Hmean 64 839.93 ( 0.00%) 840.77 ( 0.10%) 841.02 ( 0.13%)
Hmean 128 1614.22 ( 0.00%) 1622.07 * 0.49%* 1636.41 * 1.37%*
Hmean 256 2952.00 ( 0.00%) 2953.19 ( 0.04%) 2977.76 * 0.87%*
Hmean 1024 10291.67 ( 0.00%) 10239.17 ( -0.51%) 10434.41 * 1.39%*
Hmean 2048 17335.08 ( 0.00%) 17399.97 ( 0.37%) 17134.81 * -1.16%*
Hmean 3312 22628.15 ( 0.00%) 22471.97 ( -0.69%) 22422.78 ( -0.91%)
Hmean 4096 25009.50 ( 0.00%) 24752.83 * -1.03%* 24740.41 ( -1.08%)
Hmean 8192 32745.01 ( 0.00%) 31682.63 * -3.24%* 32153.50 * -1.81%*
Hmean 16384 39759.59 ( 0.00%) 36805.78 * -7.43%* 38948.13 * -2.04%*

On a 1-socket skylake machine with a small CPU cache that suffers more if
cache misses are too high

netperf-tcp
5.17.0-rc3 5.17.0-rc3 5.17.0-rc3
vanilla mm-reverthighpcp-v1 mm-highpcplimit-v2
Hmean 64 938.95 ( 0.00%) 941.50 * 0.27%* 943.61 * 0.50%*
Hmean 128 1843.10 ( 0.00%) 1857.58 * 0.79%* 1861.09 * 0.98%*
Hmean 256 3573.07 ( 0.00%) 3667.45 * 2.64%* 3674.91 * 2.85%*
Hmean 1024 13206.52 ( 0.00%) 13487.80 * 2.13%* 13393.21 * 1.41%*
Hmean 2048 22870.23 ( 0.00%) 23337.96 * 2.05%* 23188.41 * 1.39%*
Hmean 3312 31001.99 ( 0.00%) 32206.50 * 3.89%* 31863.62 * 2.78%*
Hmean 4096 35364.59 ( 0.00%) 36490.96 * 3.19%* 36112.54 * 2.11%*
Hmean 8192 48497.71 ( 0.00%) 49954.05 * 3.00%* 49588.26 * 2.25%*
Hmean 16384 58410.86 ( 0.00%) 60839.80 * 4.16%* 62282.96 * 6.63%*

Note that this was a machine that did not benefit from caching high-order
pages and performance is almost restored with the series applied. It's
not fully restored as cache misses are still higher. This is a trade-off
between optimising for a workload that does all allocs on one CPU and
frees on another or more general workloads that need high-order pages for
SLUB and benefit from avoiding zone->lock for every SLUB refill/drain.

Link: https://lkml.kernel.org/r/20220217002227.5739-7-mgorman@techsingularity.net
Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Reviewed-by: Vlastimil Babka <vbabka@suse.cz>
Tested-by: Aaron Lu <aaron.lu@intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Jesper Dangaard Brouer <brouer@redhat.com>
Cc: Michal Hocko <mhocko@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Completed in 1110 milliseconds