OSDN Git Service
Tyler Nijmeh [Fri, 24 May 2019 20:49:55 +0000 (13:49 -0700)]
mm: Increase vmstat interval
Red Hat linux states that vmstat updates can be mildly expensive.
Increase from 1 second to 10 seconds.
Signed-off-by: Tyler Nijmeh <tylernij@gmail.com>
Julian Liu [Tue, 17 Sep 2019 14:01:28 +0000 (22:01 +0800)]
zram: Limit the max disksize to 2GB
Philip Cuadra [Thu, 18 Jan 2018 19:32:26 +0000 (11:32 -0800)]
msm: bus_arb: disable debug logging
This debug logging consumes 10% of all the cpu cycles in the drivers
communicating with the dsp. Disable the logging for the time being
until it we add a config.
Bug:
71867957
Change-Id: I97d418fee3d4576b077ed284ed5ae4447da5a789
Signed-off-by: Philip Cuadra <philipcuadra@google.com>
Signed-off-by: Park Ju Hyung <qkrwngud825@gmail.com>
kdrag0n [Sun, 23 Dec 2018 06:29:33 +0000 (22:29 -0800)]
block: disable random pool contribution by default
Signed-off-by: kdrag0n <dragon@khronodragon.com>
wloot [Thu, 6 Jun 2019 07:04:53 +0000 (15:04 +0800)]
phy: Do not compile unused drivers
Ard Biesheuvel [Wed, 11 Jan 2017 16:41:52 +0000 (16:41 +0000)]
BACKPORT: crypto: arm64/aes - add scalar implementation
This adds a scalar implementation of AES, based on the precomputed tables
that are exposed by the generic AES code. Since rotates are cheap on arm64,
this implementation only uses the 4 core tables (of 1 KB each), and avoids
the prerotated ones, reducing the D-cache footprint by 75%.
On Cortex-A57, this code manages 13.0 cycles per byte, which is ~34% faster
than the generic C code. (Note that this is still >13x slower than the code
that uses the optional ARMv8 Crypto Extensions, which manages <1 cycles per
byte.)
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
(cherry picked from commit
bed593c0e852f5c1efd3ca4e984fd744c51cf6ee)
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Alin Jerpelea [Sat, 1 Jul 2017 06:10:54 +0000 (08:10 +0200)]
tty: serial: msm_serial_hs: fix ipclog spam
ifdef CONFIG_IPC_LOGGING functions to fix spam when config is
not enabled
Signed-off-by: Alin Jerpelea <alin.jerpelea@sonymobile.com>
Signed-off-by: celtare21 <celtare21@gmail.com>
Angelo G. Del Regno [Sat, 27 May 2017 15:36:11 +0000 (17:36 +0200)]
soc: qcom: Further fixes for !IPC_LOGGING for IPA, SMD, SMEM.
Do not crash when IPC_LOGGING is not activated.
Signed-off-by: celtare21 <celtare21@gmail.com>
Alin Jerpelea [Wed, 4 Jan 2017 15:51:53 +0000 (16:51 +0100)]
soc: qcom: stop spam when IPC_LOGGING is disabled
Signed-off-by: Alin Jerpelea <alin.jerpelea@sonymobile.com>
Aaron Lu [Fri, 17 Aug 2018 22:49:14 +0000 (15:49 -0700)]
mm, page_alloc: double zone's batchsize
To improve page allocator's performance for order-0 pages, each CPU has
a Per-CPU-Pageset(PCP) per zone. Whenever an order-0 page is needed,
PCP will be checked first before asking pages from Buddy. When PCP is
used up, a batch of pages will be fetched from Buddy to improve
performance and the size of batch can affect performance.
zone's batch size gets doubled last time by commit
ba56e91c9401("mm:
page_alloc: increase size of per-cpu-pages") over ten years ago. Since
then, CPU has envolved a lot and CPU's cache sizes also increased.
Dave Hansen is concerned the current batch size doesn't fit well with
modern hardware and suggested me to do two things: first, use a page
allocator intensive benchmark, e.g. will-it-scale/page_fault1 to find
out how performance changes with different batch sizes on various
machines and then choose a new default batch size; second, see how this
new batch size work with other workloads.
In the first test, we saw performance gains on high-core-count systems
and little to no effect on older systems with more modest core counts.
In this phase's test data, two candidates: 63 and 127 are chosen.
In the second step, ebizzy, oltp, kbuild, pigz, netperf, vm-scalability
and more will-it-scale sub-tests are tested to see how these two
candidates work with these workloads and decides a new default according
to their results.
Most test results are flat. will-it-scale/page_fault2 process mode has
10%-18% performance increase on 4-sockets Skylake and Broadwell.
vm-scalability/lru-file-mmap-read has 17%-47% performance increase for
4-sockets servers while for 2-sockets servers, it caused 3%-8% performance
drop. Further analysis showed that, with a larger pcp->batch and thus
larger pcp->high(the relationship of pcp->high=6 * pcp->batch is
maintained in this patch), zone lock contention shifted to LRU add side
lock contention and that caused performance drop. This performance drop
might be mitigated by others' work on optimizing LRU lock.
Another downside of increasing pcp->batch is, when PCP is used up and need
to fetch a batch of pages from Buddy, since batch is increased, that time
can be longer than before. My understanding is, this doesn't affect
slowpath where direct reclaim and compaction dominates. For fastpath,
throughput is a win(according to will-it-scale/page_fault1) but worst
latency can be larger now.
Overall, I think double the batch size from 31 to 63 is relatively safe
and provide good performance boost for high-core-count systems.
The two phase's test results are listed below(all tests are done with THP
disabled).
Phase one(will-it-scale/page_fault1) test results:
Skylake-EX: increased batch size has a good effect on zone->lock
contention, though LRU contention will rise at the same time and
limited the final performance increase.
batch score change zone_contention lru_contention total_contention
31
15345900 +0.00% 64% 8% 72%
53
17903847 +16.67% 32% 38% 70%
63
17992886 +17.25% 24% 45% 69%
73
18022825 +17.44% 10% 61% 71%
119
18023401 +17.45% 4% 66% 70%
127
18029012 +17.48% 3% 66% 69%
137
18036075 +17.53% 4% 66% 70%
165
18035964 +17.53% 2% 67% 69%
188
18101105 +17.95% 2% 67% 69%
223
18130951 +18.15% 2% 67% 69%
255
18118898 +18.07% 2% 67% 69%
267
18101559 +17.96% 2% 67% 69%
299
18160468 +18.34% 2% 68% 70%
320
18139845 +18.21% 2% 67% 69%
393
18160869 +18.34% 2% 68% 70%
424
18170999 +18.41% 2% 68% 70%
458
18144868 +18.24% 2% 68% 70%
467
18142366 +18.22% 2% 68% 70%
498
18154549 +18.30% 1% 68% 69%
511
18134525 +18.17% 1% 69% 70%
Broadwell-EX: similar pattern as Skylake-EX.
batch score change zone_contention lru_contention total_contention
31
16703983 +0.00% 67% 7% 74%
53
18195393 +8.93% 43% 28% 71%
63
18288885 +9.49% 38% 33% 71%
73
18344329 +9.82% 35% 37% 72%
119
18535529 +10.96% 24% 46% 70%
127
18513596 +10.83% 23% 48% 71%
137
18514327 +10.84% 23% 48% 71%
165
18511840 +10.82% 22% 49% 71%
188
18593478 +11.31% 17% 53% 70%
223
18601667 +11.36% 17% 52% 69%
255
18774825 +12.40% 12% 58% 70%
267
18754781 +12.28% 9% 60% 69%
299
18892265 +13.10% 7% 63% 70%
320
18873812 +12.99% 8% 62% 70%
393
18891174 +13.09% 6% 64% 70%
424
18975108 +13.60% 6% 64% 70%
458
18932364 +13.34% 8% 62% 70%
467
18960891 +13.51% 5% 65% 70%
498
18944526 +13.41% 5% 64% 69%
511
18960839 +13.51% 5% 64% 69%
Skylake-EP: although increased batch reduced zone->lock contention, but
the effect is not as good as EX: zone->lock contention is still as high as
20% with a very high batch value instead of 1% on Skylake-EX or 5% on
Broadwell-EX. Also, total_contention actually decreased with a higher
batch but that doesn't translate to performance increase.
batch score change zone_contention lru_contention total_contention
31
9554867 +0.00% 66% 3% 69%
53
9855486 +3.15% 63% 3% 66%
63
9980145 +4.45% 62% 4% 66%
73
10092774 +5.63% 62% 5% 67%
119
10310061 +7.90% 45% 19% 64%
127
10342019 +8.24% 42% 19% 61%
137
10358182 +8.41% 42% 21% 63%
165
10397060 +8.81% 37% 24% 61%
188
10341808 +8.24% 34% 26% 60%
223
10349135 +8.31% 31% 27% 58%
255
10327189 +8.08% 28% 29% 57%
267
10344204 +8.26% 27% 29% 56%
299
10325043 +8.06% 25% 30% 55%
320
10310325 +7.91% 25% 31% 56%
393
10293274 +7.73% 21% 31% 52%
424
10311099 +7.91% 21% 32% 53%
458
10321375 +8.02% 21% 32% 53%
467
10303881 +7.84% 21% 32% 53%
498
10332462 +8.14% 20% 33% 53%
511
10325016 +8.06% 20% 32% 52%
Broadwell-EP: zone->lock and lru lock had an agreement to make sure
performance doesn't increase and they successfully managed to keep total
contention at 70%.
batch score change zone_contention lru_contention total_contention
31
10121178 +0.00% 19% 50% 69%
53
10142366 +0.21% 6% 63% 69%
63
10117984 -0.03% 11% 58% 69%
73
10123330 +0.02% 7% 63% 70%
119
10108791 -0.12% 2% 67% 69%
127
10166074 +0.44% 3% 66% 69%
137
10141574 +0.20% 3% 66% 69%
165
10154499 +0.33% 2% 68% 70%
188
10124921 +0.04% 2% 67% 69%
223
10137399 +0.16% 2% 67% 69%
255
10143289 +0.22% 0% 68% 68%
267
10123535 +0.02% 1% 68% 69%
299
10140952 +0.20% 0% 68% 68%
320
10163170 +0.41% 0% 68% 68%
393
10000633 -1.19% 0% 69% 69%
424
10087998 -0.33% 0% 69% 69%
458
10187116 +0.65% 0% 69% 69%
467
10146790 +0.25% 0% 69% 69%
498
10197958 +0.76% 0% 69% 69%
511
10152326 +0.31% 0% 69% 69%
Haswell-EP: similar to Broadwell-EP.
batch score change zone_contention lru_contention total_contention
31
10442205 +0.00% 14% 48% 62%
53
10442255 +0.00% 5% 57% 62%
63
10452059 +0.09% 6% 57% 63%
73
10482349 +0.38% 5% 59% 64%
119
10454644 +0.12% 3% 60% 63%
127
10431514 -0.10% 3% 59% 62%
137
10423785 -0.18% 3% 60% 63%
165
10481216 +0.37% 2% 61% 63%
188
10448755 +0.06% 2% 61% 63%
223
10467144 +0.24% 2% 61% 63%
255
10480215 +0.36% 2% 61% 63%
267
10484279 +0.40% 2% 61% 63%
299
10466450 +0.23% 2% 61% 63%
320
10452578 +0.10% 2% 61% 63%
393
10499678 +0.55% 1% 62% 63%
424
10481454 +0.38% 1% 62% 63%
458
10473562 +0.30% 1% 62% 63%
467
10484269 +0.40% 0% 62% 62%
498
10505599 +0.61% 0% 62% 62%
511
10483395 +0.39% 0% 62% 62%
Westmere-EP: contention is pretty small so not interesting. Note too high
a batch value could hurt performance.
batch score change zone_contention lru_contention total_contention
31
4831523 +0.00% 2% 3% 5%
53
4834086 +0.05% 2% 4% 6%
63
4834262 +0.06% 2% 3% 5%
73
4832851 +0.03% 2% 4% 6%
119
4830534 -0.02% 1% 3% 4%
127
4827461 -0.08% 1% 4% 5%
137
4827459 -0.08% 1% 3% 4%
165
4820534 -0.23% 0% 4% 4%
188
4817947 -0.28% 0% 3% 3%
223
4809671 -0.45% 0% 3% 3%
255
4802463 -0.60% 0% 4% 4%
267
4801634 -0.62% 0% 3% 3%
299
4798047 -0.69% 0% 3% 3%
320
4793084 -0.80% 0% 3% 3%
393
4785877 -0.94% 0% 3% 3%
424
4782911 -1.01% 0% 3% 3%
458
4779346 -1.08% 0% 3% 3%
467
4780306 -1.06% 0% 3% 3%
498
4780589 -1.05% 0% 3% 3%
511
4773724 -1.20% 0% 3% 3%
Skylake-Desktop: similar to Westmere-EP, nothing interesting.
batch score change zone_contention lru_contention total_contention
31
3906608 +0.00% 2% 3% 5%
53
3940164 +0.86% 2% 3% 5%
63
3937289 +0.79% 2% 3% 5%
73
3940201 +0.86% 2% 3% 5%
119
3933240 +0.68% 2% 3% 5%
127
3930514 +0.61% 2% 4% 6%
137
3938639 +0.82% 0% 3% 3%
165
3908755 +0.05% 0% 3% 3%
188
3905621 -0.03% 0% 3% 3%
223
3903015 -0.09% 0% 4% 4%
255
3889480 -0.44% 0% 3% 3%
267
3891669 -0.38% 0% 4% 4%
299
3898728 -0.20% 0% 4% 4%
320
3894547 -0.31% 0% 4% 4%
393
3875137 -0.81% 0% 4% 4%
424
3874521 -0.82% 0% 3% 3%
458
3880432 -0.67% 0% 4% 4%
467
3888715 -0.46% 0% 3% 3%
498
3888633 -0.46% 0% 4% 4%
511
3875305 -0.80% 0% 5% 5%
Haswell-Desktop: zone->lock is pretty low as other desktops, though lru
contention is higher than other desktops.
batch score change zone_contention lru_contention total_contention
31
3511158 +0.00% 2% 5% 7%
53
3555445 +1.26% 2% 6% 8%
63
3561082 +1.42% 2% 6% 8%
73
3547218 +1.03% 2% 6% 8%
119
3571319 +1.71% 1% 7% 8%
127
3549375 +1.09% 0% 6% 6%
137
3560233 +1.40% 0% 6% 6%
165
3555176 +1.25% 2% 6% 8%
188
3551501 +1.15% 0% 8% 8%
223
3531462 +0.58% 0% 7% 7%
255
3570400 +1.69% 0% 7% 7%
267
3532235 +0.60% 1% 8% 9%
299
3562326 +1.46% 0% 6% 6%
320
3553569 +1.21% 0% 8% 8%
393
3539519 +0.81% 0% 7% 7%
424
3549271 +1.09% 0% 8% 8%
458
3528885 +0.50% 0% 8% 8%
467
3526554 +0.44% 0% 7% 7%
498
3525302 +0.40% 0% 9% 9%
511
3527556 +0.47% 0% 8% 8%
Sandybridge-Desktop: the 0% contention isn't accurate but caused by
dropped fractional part. Since multiple contention path's contentions
are all under 1% here, with some arithmetic operations like add, the
final deviation could be as large as 3%.
batch score change zone_contention lru_contention total_contention
31
1744495 +0.00% 0% 0% 0%
53
1755341 +0.62% 0% 0% 0%
63
1758469 +0.80% 0% 0% 0%
73
1759626 +0.87% 0% 0% 0%
119
1770417 +1.49% 0% 0% 0%
127
1768252 +1.36% 0% 0% 0%
137
1767848 +1.34% 0% 0% 0%
165
1765088 +1.18% 0% 0% 0%
188
1766918 +1.29% 0% 0% 0%
223
1767866 +1.34% 0% 0% 0%
255
1768074 +1.35% 0% 0% 0%
267
1763187 +1.07% 0% 0% 0%
299
1765620 +1.21% 0% 0% 0%
320
1767603 +1.32% 0% 0% 0%
393
1764612 +1.15% 0% 0% 0%
424
1758476 +0.80% 0% 0% 0%
458
1758593 +0.81% 0% 0% 0%
467
1757915 +0.77% 0% 0% 0%
498
1753363 +0.51% 0% 0% 0%
511
1755548 +0.63% 0% 0% 0%
Phase two test results:
Note: all percent change is against base(batch=31).
ebizzy.throughput (higer is better)
machine batch=31 batch=63 batch=127
lkp-skl-4sp1
2410037±7%
2600451±2% +7.9%
2602878 +8.0%
lkp-bdw-ex1
1493328 1489243 -0.3%
1492145 -0.1%
lkp-skl-2sp2
1329674 1345891 +1.2%
1351056 +1.6%
lkp-bdw-ep2 711511 711511 0.0% 710708 -0.1%
lkp-wsm-ep2 75750 75528 -0.3% 75441 -0.4%
lkp-skl-d01 264126 262791 -0.5% 264113 +0.0%
lkp-hsw-d01 176601 176328 -0.2% 176368 -0.1%
lkp-sb02 98937 98937 +0.0% 99030 +0.1%
kbuild.buildtime (less is better)
machine batch=31 batch=63 batch=127
lkp-skl-4sp1 107.00 107.67 +0.6% 107.11 +0.1%
lkp-bdw-ex1 97.33 97.33 +0.0% 97.42 +0.1%
lkp-skl-2sp2 180.00 179.83 -0.1% 179.83 -0.1%
lkp-bdw-ep2 178.17 179.17 +0.6% 177.50 -0.4%
lkp-wsm-ep2 737.00 738.00 +0.1% 738.00 +0.1%
lkp-skl-d01 642.00 653.00 +1.7% 653.00 +1.7%
lkp-hsw-d01 1310.00 1316.00 +0.5% 1311.00 +0.1%
netperf/TCP_STREAM.Throughput_total_Mbps (higher is better)
machine batch=31 batch=63 batch=127
lkp-skl-4sp1 948790 947144 -0.2% 948333 -0.0%
lkp-bdw-ex1 904224 904366 +0.0% 904926 +0.1%
lkp-skl-2sp2 239731 239607 -0.1% 239565 -0.1%
lk-bdw-ep2 365764 365933 +0.0% 365951 +0.1%
lkp-wsm-ep2 93736 93803 +0.1% 93808 +0.1%
lkp-skl-d01 77314 77303 -0.0% 77375 +0.1%
lkp-hsw-d01 58617 60387 +3.0% 60208 +2.7%
lkp-sb02 29990 30137 +0.5% 30103 +0.4%
oltp.transactions (higer is better)
machine batch=31 batch=63 batch=127
lkp-bdw-ex1
9073276 9100377 +0.3%
9036344 -0.4%
lkp-skl-2sp2
8898717 8852054 -0.5%
8894459 -0.0%
lkp-bdw-ep2
13426155 13384654 -0.3%
13333637 -0.7%
lkp-hsw-ep2
13146314 13232784 +0.7%
13193163 +0.4%
lkp-wsm-ep2
5035355 5019348 -0.3%
5033418 -0.0%
lkp-skl-d01 418485
4413339 -0.1%
4419039 +0.0%
lkp-hsw-d01
3517817±5%
3396120±3% -3.5%
3455138±3% -1.8%
pigz.throughput (higer is better)
machine batch=31 batch=63 batch=127
lkp-skl-4sp1 1.513e+08 1.507e+08 -0.4% 1.511e+08 -0.2%
lkp-bdw-ex1 2.060e+08 2.052e+08 -0.4% 2.044e+08 -0.8%
lkp-skl-2sp2 8.836e+08 8.845e+08 +0.1% 8.836e+08 -0.0%
lkp-bdw-ep2 8.275e+08 8.464e+08 +2.3% 8.330e+08 +0.7%
lkp-wsm-ep2 2.224e+08 2.221e+08 -0.2% 2.218e+08 -0.3%
lkp-skl-d01 1.177e+08 1.177e+08 -0.0% 1.176e+08 -0.1%
lkp-hsw-d01 1.154e+08 1.154e+08 +0.1% 1.154e+08 -0.0%
lkp-sb02 0.633e+08 0.633e+08 +0.1% 0.633e+08 +0.0%
will-it-scale.malloc1.processes (higher is better)
machine batch=31 batch=63 batch=127
lkp-skl-4sp1 620181 620484 +0.0% 620240 +0.0%
lkp-bdw-ex1
1403610 1401201 -0.2%
1417900 +1.0%
lkp-skl-2sp2
1288097 1284145 -0.3%
1283907 -0.3%
lkp-bdw-ep2
1427879 1427675 -0.0%
1428266 +0.0%
lkp-hsw-ep2
1362546 1353965 -0.6%
1354759 -0.6%
lkp-wsm-ep2
2099657 2107576 +0.4%
2100226 +0.0%
lkp-skl-d01
1476835 1476358 -0.0%
1474487 -0.2%
lkp-hsw-d01
1308810 1303429 -0.4%
1301299 -0.6%
lkp-sb02 589286 589284 -0.0% 588101 -0.2%
will-it-scale.malloc1.threads (higher is better)
machine batch=31 batch=63 batch=127
lkp-skl-4sp1 21289 21125 -0.8% 21241 -0.2%
lkp-bdw-ex1 28114 28089 -0.1% 28007 -0.4%
lkp-skl-2sp2 91866 91946 +0.1% 92723 +0.9%
lkp-bdw-ep2 37637 37501 -0.4% 37317 -0.9%
lkp-hsw-ep2 43673 43590 -0.2% 43754 +0.2%
lkp-wsm-ep2 28577 28298 -1.0% 28545 -0.1%
lkp-skl-d01 175277 173343 -1.1% 173082 -1.3%
lkp-hsw-d01 130303 129566 -0.6% 129250 -0.8%
lkp-sb02 113742±3% 116911 +2.8% 116417±3% +2.4%
will-it-scale.malloc2.processes (higer is better)
machine batch=31 batch=63 batch=127
lkp-skl-4sp1 1.206e+09 1.206e+09 -0.0% 1.206e+09 +0.0%
lkp-bdw-ex1 1.319e+09 1.319e+09 -0.0% 1.319e+09 +0.0%
lkp-skl-2sp2 8.000e+08 8.021e+08 +0.3% 7.995e+08 -0.1%
lkp-bdw-ep2 6.582e+08 6.634e+08 +0.8% 6.513e+08 -1.1%
lkp-hsw-ep2 6.671e+08 6.669e+08 -0.0% 6.665e+08 -0.1%
lkp-wsm-ep2 1.805e+08 1.806e+08 +0.0% 1.804e+08 -0.1%
lkp-skl-d01 1.611e+08 1.611e+08 -0.0% 1.610e+08 -0.0%
lkp-hsw-d01 1.333e+08 1.332e+08 -0.0% 1.332e+08 -0.0%
lkp-sb02
82485104 82478206 -0.0%
82473546 -0.0%
will-it-scale.malloc2.threads (higer is better)
machine batch=31 batch=63 batch=127
lkp-skl-4sp1 1.574e+09 1.574e+09 -0.0% 1.574e+09 -0.0%
lkp-bdw-ex1 1.737e+09 1.737e+09 +0.0% 1.737e+09 -0.0%
lkp-skl-2sp2 9.161e+08 9.162e+08 +0.0% 9.181e+08 +0.2%
lkp-bdw-ep2 7.856e+08 8.015e+08 +2.0% 8.113e+08 +3.3%
lkp-hsw-ep2 6.908e+08 6.904e+08 -0.1% 6.907e+08 -0.0%
lkp-wsm-ep2 2.409e+08 2.409e+08 +0.0% 2.409e+08 -0.0%
lkp-skl-d01 1.199e+08 1.199e+08 -0.0% 1.199e+08 -0.0%
lkp-hsw-d01 1.029e+08 1.029e+08 -0.0% 1.029e+08 +0.0%
lkp-sb02
68081213 68061423 -0.0%
68076037 -0.0%
will-it-scale.page_fault2.processes (higer is better)
machine batch=31 batch=63 batch=127
lkp-skl-4sp1
14509125±4%
16472364 +13.5%
17123117 +18.0%
lkp-bdw-ex1
14736381 16196588 +9.9%
16364011 +11.0%
lkp-skl-2sp2
6354925 6435444 +1.3%
6436644 +1.3%
lkp-bdw-ep2
8749584 8834422 +1.0%
8827179 +0.9%
lkp-hsw-ep2
8762591 8845920 +1.0%
8825697 +0.7%
lkp-wsm-ep2
3036083 3030428 -0.2%
3021741 -0.5%
lkp-skl-d01
2307834 2304731 -0.1%
2286142 -0.9%
lkp-hsw-d01
1806237 1800786 -0.3%
1795943 -0.6%
lkp-sb02 842616 837844 -0.6% 833921 -1.0%
will-it-scale.page_fault2.threads
machine batch=31 batch=63 batch=127
lkp-skl-4sp1
1623294 1615132±2% -0.5%
1656777 +2.1%
lkp-bdw-ex1
1995714 2025948 +1.5%
2113753±3% +5.9%
lkp-skl-2sp2
2346708 2415591 +2.9%
2416919 +3.0%
lkp-bdw-ep2
2342564 2344882 +0.1%
2300206 -1.8%
lkp-hsw-ep2
1820658 1831681 +0.6%
1844057 +1.3%
lkp-wsm-ep2
1725482 1733774 +0.5%
1740517 +0.9%
lkp-skl-d01
1832833 1823628 -0.5%
1806489 -1.4%
lkp-hsw-d01
1427913 1427287 -0.0%
1420226 -0.5%
lkp-sb02 750626 748615 -0.3% 746621 -0.5%
will-it-scale.page_fault3.processes (higher is better)
machine batch=31 batch=63 batch=127
lkp-skl-4sp1
24382726 24400317 +0.1%
24668774 +1.2%
lkp-bdw-ex1
35399750 35683124 +0.8%
35829492 +1.2%
lkp-skl-2sp2
28136820 28068248 -0.2%
28147989 +0.0%
lkp-bdw-ep2
37269077 37459490 +0.5%
37373073 +0.3%
lkp-hsw-ep2
36224967 36114085 -0.3%
36104908 -0.3%
lkp-wsm-ep2
16820457 16911005 +0.5%
16968596 +0.9%
lkp-skl-d01
7721138 7725904 +0.1%
7756740 +0.5%
lkp-hsw-d01
7611979 7650928 +0.5%
7651323 +0.5%
lkp-sb02
3781546 3796502 +0.4%
3796827 +0.4%
will-it-scale.page_fault3.threads (higer is better)
machine batch=31 batch=63 batch=127
lkp-skl-4sp1
1865820±3%
1900917±2% +1.9%
1826245±4% -2.1%
lkp-bdw-ex1
3094060 3148326 +1.8%
3150036 +1.8%
lkp-skl-2sp2
3952940 3953898 +0.0%
3989360 +0.9%
lkp-bdw-ep2
3420373±3%
3643964 +6.5%
3644910±5% +6.6%
lkp-hsw-ep2
2609635±2%
2582310±3% -1.0%
2780459 +6.5%
lkp-wsm-ep2
4395001 4417196 +0.5%
4432499 +0.9%
lkp-skl-d01
5363977 5400003 +0.7%
5411370 +0.9%
lkp-hsw-d01
5274131 5311294 +0.7%
5319359 +0.9%
lkp-sb02
2917314 2913004 -0.1%
2935286 +0.6%
will-it-scale.read1.processes (higer is better)
machine batch=31 batch=63 batch=127
lkp-skl-4sp1
73762279±14%
69322519±10% -6.0%
69349855±13% -6.0% (result unstable)
lkp-bdw-ex1 1.701e+08 1.704e+08 +0.1% 1.705e+08 +0.2%
lkp-skl-2sp2
63111570 63113953 +0.0%
63836573 +1.1%
lkp-bdw-ep2
79247409 79424610 +0.2%
78012656 -1.6%
lkp-hsw-ep2
67677026 68308800 +0.9%
67539106 -0.2%
lkp-wsm-ep2
13339630 13939817 +4.5%
13766865 +3.2%
lkp-skl-d01
10969487 10972650 +0.0% no data
lkp-hsw-d01
9857342±2%
10080592±2% +2.3%
10131560 +2.8%
lkp-sb02
5189076 5197473 +0.2%
5163253 -0.5%
will-it-scale.read1.threads (higher is better)
machine batch=31 batch=63 batch=127
lkp-skl-4sp1
62468045±12%
73666726±7% +17.9%
79553123±12% +27.4% (result unstable)
lkp-bdw-ex1 1.62e+08 1.624e+08 +0.3% 1.614e+08 -0.3%
lkp-skl-2sp2
58319780 59181032 +1.5%
59821353 +2.6%
lkp-bdw-ep2
74057992 75698171 +2.2%
74990869 +1.3%
lkp-hsw-ep2
63672959 63639652 -0.1%
64387051 +1.1%
lkp-wsm-ep2
13489943 13526058 +0.3%
13259032 -1.7%
lkp-skl-d01
10297906 10338796 +0.4%
10407328 +1.1%
lkp-hsw-d01
9636721 9667376 +0.3%
9341147 -3.1%
lkp-sb02
4801938 4804496 +0.1%
4802290 +0.0%
will-it-scale.write1.processes (higer is better)
machine batch=31 batch=63 batch=127
lkp-skl-4sp1 1.111e+08 1.104e+08±2% -0.7% 1.122e+08±2% +1.0%
lkp-bdw-ex1 1.392e+08 1.399e+08 +0.5% 1.397e+08 +0.4%
lkp-skl-2sp2
59369233 58994841 -0.6%
58715168 -1.1%
lkp-bdw-ep2
61820979 CPU throttle
63593123 +2.9%
lkp-hsw-ep2
57897587 57435605 -0.8%
56347450 -2.7%
lkp-wsm-ep2
7814203 7918017±2% +1.3%
7669068 -1.9%
lkp-skl-d01
8886557 8971422 +1.0%
8818366 -0.8%
lkp-hsw-d01
9171001±5%
9189915 +0.2%
9483909 +3.4%
lkp-sb02
4475406 4475294 -0.0%
4501756 +0.6%
will-it-scale.write1.threads (higer is better)
machine batch=31 batch=63 batch=127
lkp-skl-4sp1 1.058e+08 1.055e+08±2% -0.2% 1.065e+08 +0.7%
lkp-bdw-ex1 1.316e+08 1.300e+08 -1.2% 1.308e+08 -0.6%
lkp-skl-2sp2
54492421 56086678 +2.9%
55975657 +2.7%
lkp-bdw-ep2
59360449 59003957 -0.6%
58101262 -2.1%
lkp-hsw-ep2
53346346±2%
52530876 -1.5%
52902487 -0.8%
lkp-wsm-ep2
7774006 7800092±2% +0.3%
7558833 -2.8%
lkp-skl-d01
8346174 8235695 -1.3% no data
lkp-hsw-d01
8636244 8655731 +0.2%
8658868 +0.3%
lkp-sb02
4181820 4204107 +0.5%
4182992 +0.0%
vm-scalability.anon-r-rand.throughput (higher is better)
machine batch=31 batch=63 batch=127
lkp-skl-4sp1
11933873±3%
12356544±2% +3.5%
12188624 +2.1%
lkp-bdw-ex1
7114424±2%
7330949±2% +3.0%
7392419 +3.9%
lkp-skl-2sp2
6773277±5%
6492332±8% -4.1%
6543962 -3.4%
lkp-bdw-ep2
7133846±4%
7233508 +1.4%
7013518±3% -1.7%
lkp-hsw-ep2
4576626 4527098 -1.1%
4551679 -0.5%
lkp-wsm-ep2
2583599 2592492 +0.3%
2588039 +0.2%
lkp-hsw-d01 998199±2%
1028311 +3.0%
1006460±2% +0.8%
lkp-sb02 570572 567854 -0.5% 568449 -0.4%
vm-scalability.anon-r-rand-mt.throughput (higher is better)
machine batch=31 batch=63 batch=127
lkp-skl-4sp1
1789419 1787830 -0.1%
1788208 -0.1%
lkp-bdw-ex1
3492595±2%
3554966±2% +1.8%
3558835±3% +1.9%
lkp-skl-2sp2
3856238±2%
3975403±4% +3.1%
3994600 +3.6%
lkp-bdw-ep2
3726963±11%
3809292±6% +2.2%
3871924±4% +3.9%
lkp-hsw-ep2
2131760±3%
2033578±4% -4.6%
2130727±6% -0.0%
lkp-wsm-ep2
2369731 2368384 -0.1%
2370252 +0.0%
lkp-skl-d01
1207128 1206220 -0.1%
1205801 -0.1%
lkp-hsw-d01 964317 992329±2% +2.9% 992099±2% +2.9%
lkp-sb02 567137 567346 +0.0% 566144 -0.2%
vm-scalability.lru-file-mmap-read.throughput (higher is better)
machine batch=31 batch=63 batch=127
lkp-skl-4sp1
19560469±6%
23018999 +17.7%
23418800 +19.7%
lkp-bdw-ex1
17769135±14%
26141676±3% +47.1%
26284723±5% +47.9%
lkp-skl-2sp2
14056512 13578884 -3.4%
13146214 -6.5%
lkp-bdw-ep2
15336542 14737654 -3.9%
14088159 -8.1%
lkp-hsw-ep2
16275498 15756296 -3.2%
15018090 -7.7%
lkp-wsm-ep2
11272160 11237231 -0.3%
11310047 +0.3%
lkp-skl-d01
7322119 7324569 +0.0%
7184148 -1.9%
lkp-hsw-d01
6449234 6404542 -0.7%
6356141 -1.4%
lkp-sb02
3517943 3520668 +0.1%
3527309 +0.3%
vm-scalability.lru-file-mmap-read-rand.throughput (higher is better)
machine batch=31 batch=63 batch=127
lkp-skl-4sp1
1689052 1697553 +0.5%
1698726 +0.6%
lkp-bdw-ex1
1675246 1699764 +1.5%
1712226 +2.2%
lkp-skl-2sp2
1800533 1799749 -0.0%
1800581 +0.0%
lkp-bdw-ep2
1807422 1807758 +0.0%
1804932 -0.1%
lkp-hsw-ep2
1809807 1808781 -0.1%
1807811 -0.1%
lkp-wsm-ep2
1800198 1802434 +0.1%
1801236 +0.1%
lkp-skl-d01 696689 695537 -0.2% 694106 -0.4%
lkp-hsw-d01 698364 698666 +0.0% 696686 -0.2%
lkp-sb02 258939 258787 -0.1% 258199 -0.3%
Link: http://lkml.kernel.org/r/20180711055855.29072-1-aaron.lu@intel.com
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Suggested-by: Dave Hansen <dave.hansen@intel.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>
Cc: Huang Ying <ying.huang@intel.com>
Cc: Kemi Wang <kemi.wang@intel.com>
Cc: Tim Chen <tim.c.chen@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Jesper Dangaard Brouer <brouer@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: celtare21 <celtare21@gmail.com>
Ard Biesheuvel [Tue, 21 Nov 2017 13:40:17 +0000 (13:40 +0000)]
BACKPORT: crypto: arm64/aes-ce-cipher - move assembler code to .S file
Most crypto drivers involving kernel mode NEON take care to put the code
that actually touches the NEON register file in a separate compilation
unit, to prevent the compiler from reordering code that preserves or
restores the NEON context with code that may corrupt it. This is
necessary because we currently have no way to express the restrictions
imposed upon use of the NEON in kernel mode in a way that the compiler
understands.
However, in the case of aes-ce-cipher, it did not seem unreasonable to
deviate from this rule, given how it does not seem possible for the
compiler to reorder cross object function calls with asm blocks whose
in- and output constraints reflect that it reads from and writes to
memory.
Now that LTO is being proposed for the arm64 kernel, it is time to
revisit this. The link time optimization may replace the function
calls to kernel_neon_begin() and kernel_neon_end() with instantiations
of the IR that make up its implementation, allowing further reordering
with the asm block.
So let's clean this up, and move the asm() blocks into a separate .S
file.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-By: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
(cherry picked from commit
019cd46984d04703a39924178f503a98436ac0d7)
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Ard Biesheuvel [Mon, 24 Jul 2017 10:28:11 +0000 (11:28 +0100)]
UPSTREAM: crypto: arm64/aes-ce-cipher: add non-SIMD generic fallback
The arm64 kernel will shortly disallow nested kernel mode NEON, so
add a fallback to scalar code that can be invoked in that case.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
(cherry picked from commit
b8fb993a836cd432309410eadf083bbe9c0e9e9c)
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Ard Biesheuvel [Mon, 24 Jul 2017 10:28:10 +0000 (11:28 +0100)]
UPSTREAM: crypto: arm64/aes-ce-cipher - match round key endianness with generic code
In order to be able to reuse the generic AES code as a fallback for
situations where the NEON may not be used, update the key handling
to match the byte order of the generic code: it stores round keys
as sequences of 32-bit quantities rather than streams of bytes, and
so our code needs to be updated to reflect that.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
(cherry picked from commit
f402e3115e20b345bd6fbfcf463a506d958c7bf6)
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Danny Lin [Thu, 11 Jul 2019 02:18:40 +0000 (19:18 -0700)]
Makefile: Use pipes rather than temporary files for intermediate steps
GCC supports the use of pipes for intermediate compilation steps (e.g.
passing the generated assembly code to the assembler) as a replacement for
temporary files. This bypasses VFS and other layers which can introduce
substantial amounts of overhead and instead redirects data directly
between processes.
The final product and generated code are unaffected. Memory usage while
compiling is slightly higher.
Tests showed a substantial reduction in build time when using GCC to
compile an x86 4.19 kernel:
Using temporary files in tmpfs: 2m41s
Using pipes: 2m36s
Similar benefits were observed with an Android arm64 4.9 kernel:
Using tmpfs: 5m34s
Using pipes: 4m33s
Enable the feature when possible (i.e. when the compiler supports it) to
speed up builds at effectively no cost for many setups, particularly
those with weaker CPUs.
Test: kernel compiles and boots
Signed-off-by: Danny Lin <danny@kdrag0n.dev>
celtare21 [Wed, 6 Feb 2019 15:05:13 +0000 (15:05 +0000)]
msm8998: Pool msm-thermal every 200ms
Signed-off-by: celtare21 <celtare21@gmail.com>
Park Ju Hyung [Sun, 7 Jul 2019 17:43:37 +0000 (02:43 +0900)]
adreno: hardcode for A540v2
Signed-off-by: Park Ju Hyung <qkrwngud825@gmail.com>
[wight554: adapted A630 change for A540v2]
Signed-off-by: Volodymyr Zhdanov <wight554@gmail.com>
kdrag0n [Tue, 13 Nov 2018 05:43:38 +0000 (21:43 -0800)]
gpu: adreno: only compile Adreno 5xx driver
We won't be using this with an Adreno 3xx/4xx GPU.
Signed-off-by: kdrag0n <dragon@khronodragon.com>
[wight554: adapted 6xx change for 5xx]
Signed-off-by: Volodymyr Zhdanov <wight554@gmail.com>
Prasad Sodagudi [Mon, 24 Sep 2018 23:25:55 +0000 (16:25 -0700)]
kernel: time: Add delay after cpu_relax() in tight loops
Tight loops of spin_lock_irqsave() and spin_unlock_irqrestore()
in timer and hrtimer are causing scheduling delays. Add delay of
few nano seconds after cpu_relax in the timer/hrtimer tight loops.
Change-Id: Iaa0ab92da93f7b245b1d922b6edca2bebdc0fbce
Signed-off-by: Prasad Sodagudi <psodagud@codeaurora.org>
[wight554: fix conflicts in kernel/time/{hrtimer.c,tick-internal.h}]
Signed-off-by: Volodymyr Zhdanov <wight554@gmail.com>
Liam Mark [Mon, 7 Jan 2019 20:07:25 +0000 (12:07 -0800)]
ion: ensure prefetch/drain requests are processed in order
Currently when there is an ION prefetch or drain request we are adding
them to the start of the prefetch_list list.
This can cause the requests to be processed in the wrong order, for
example if there is a prefetch request made followed by a drain request
(before the prefetch request has been processed) the the drain request
will be handled first.
Ensure prefetch and drain requests are processed in order by appending
requests to the end of the prefetch_list list
Change-Id: I935a0d69a52267e888e9b19e1e8c0d9bd68e295b
Signed-off-by: Liam Mark <lmark@codeaurora.org>
Prakash Kamliya [Thu, 27 Dec 2018 13:06:08 +0000 (18:36 +0530)]
msm: kgsl: Relax adreno spin idle tight loop
Tight loop of adreno_spin_idle() causing RT throttling.
Relax the tight loop by giving chance to other thread.
Change-Id: Ic23d4551c0cc0b5f2fa7844ca73444d1412d480c
Signed-off-by: Prakash Kamliya <pkamliya@codeaurora.org>
Rick Yiu [Wed, 26 Sep 2018 08:45:50 +0000 (16:45 +0800)]
ANDROID: block/cfq-iosched: make group_idle per io cgroup tunable
If group_idle is made per io cgroup tunable, it gives more flexibility
in tuning the performance of each group. If no value is set, it will
just use the original default value.
Bug:
117857342
Bug:
132282125
Test: values could be set to each group correctly
Signed-off-by: Rick Yiu <rickyiu@google.com>
Change-Id: I9aba172419f1819f459e8305b909630fa8305978
Bart Van Assche [Tue, 7 Aug 2018 23:17:29 +0000 (16:17 -0700)]
cfq: Suppress compiler warnings about comparisons
This patch does not change any functionality but avoids that gcc
reports the following warnings when building with W=1:
block/cfq-iosched.c: In function ?cfq_back_seek_max_store?:
block/cfq-iosched.c:4741:13: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
if (__data < (MIN)) \
^
block/cfq-iosched.c:4756:1: note: in expansion of macro ?STORE_FUNCTION?
STORE_FUNCTION(cfq_back_seek_max_store, &cfqd->cfq_back_max, 0, UINT_MAX, 0);
^~~~~~~~~~~~~~
block/cfq-iosched.c: In function ?cfq_slice_idle_store?:
block/cfq-iosched.c:4741:13: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
if (__data < (MIN)) \
^
block/cfq-iosched.c:4759:1: note: in expansion of macro ?STORE_FUNCTION?
STORE_FUNCTION(cfq_slice_idle_store, &cfqd->cfq_slice_idle, 0, UINT_MAX, 1);
^~~~~~~~~~~~~~
block/cfq-iosched.c: In function ?cfq_group_idle_store?:
block/cfq-iosched.c:4741:13: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
if (__data < (MIN)) \
^
block/cfq-iosched.c:4760:1: note: in expansion of macro ?STORE_FUNCTION?
STORE_FUNCTION(cfq_group_idle_store, &cfqd->cfq_group_idle, 0, UINT_MAX, 1);
^~~~~~~~~~~~~~
block/cfq-iosched.c: In function ?cfq_low_latency_store?:
block/cfq-iosched.c:4741:13: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
if (__data < (MIN)) \
^
block/cfq-iosched.c:4765:1: note: in expansion of macro ?STORE_FUNCTION?
STORE_FUNCTION(cfq_low_latency_store, &cfqd->cfq_latency, 0, 1, 0);
^~~~~~~~~~~~~~
block/cfq-iosched.c: In function ?cfq_slice_idle_us_store?:
block/cfq-iosched.c:4775:13: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
if (__data < (MIN)) \
^
block/cfq-iosched.c:4782:1: note: in expansion of macro ?USEC_STORE_FUNCTION?
USEC_STORE_FUNCTION(cfq_slice_idle_us_store, &cfqd->cfq_slice_idle, 0, UINT_MAX);
^~~~~~~~~~~~~~~~~~~
block/cfq-iosched.c: In function ?cfq_group_idle_us_store?:
block/cfq-iosched.c:4775:13: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
if (__data < (MIN)) \
^
block/cfq-iosched.c:4783:1: note: in expansion of macro ?USEC_STORE_FUNCTION?
USEC_STORE_FUNCTION(cfq_group_idle_us_store, &cfqd->cfq_group_idle, 0, UINT_MAX);
^~~~~~~~~~~~~~~~~~~
Signed-off-by: Bart Van Assche <bart.vanassche@wdc.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
[wight554: fix 4.4 backport conflicts]
Signed-off-by: Volodymyr Zhdanov <wight554@gmail.com>
Bart Van Assche [Tue, 7 Aug 2018 23:17:28 +0000 (16:17 -0700)]
cfq: Annotate fall-through in a switch statement
This patch avoids that gcc complains about fall-through when building
with W=1.
Signed-off-by: Bart Van Assche <bart.vanassche@wdc.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Hou Tao [Wed, 1 Mar 2017 01:02:33 +0000 (09:02 +0800)]
cfq-iosched: fix the delay of cfq_group's vdisktime under iops mode
When adding a cfq_group into the cfq service tree, we use CFQ_IDLE_DELAY
as the delay of cfq_group's vdisktime if there have been other cfq_groups
already.
When cfq is under iops mode, commit
9a7f38c42c2b ("cfq-iosched: Convert
from jiffies to nanoseconds") could result in a large iops delay and
lead to an abnormal io schedule delay for the added cfq_group. To fix
it, we just need to revert to the old CFQ_IDLE_DELAY value: HZ / 5
when iops mode is enabled.
Despite having the same value, the delay of a cfq_queue in idle class
and the delay of cfq_group are different things, so I define two new
macros for the delay of a cfq_group under time-slice mode and iops mode.
Fixes:
9a7f38c42c2b ("cfq-iosched: Convert from jiffies to nanoseconds")
Cc: <stable@vger.kernel.org> # 4.8+
Signed-off-by: Hou Tao <houtao1@huawei.com>
Acked-by: Jan Kara <jack@suse.cz>
Signed-off-by: Jens Axboe <axboe@fb.com>
Matthias Kaehlcke [Fri, 26 May 2017 21:22:37 +0000 (14:22 -0700)]
cfq-iosched: Delete unused function min_vdisktime()
This fixes the following warning when building with clang:
block/cfq-iosched.c:970:19: error: unused function 'min_vdisktime'
[-Werror,-Wunused-function]
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Jens Axboe <axboe@fb.com>
Markus Elfring [Sat, 21 Jan 2017 21:44:07 +0000 (22:44 +0100)]
cfq-iosched: Adjust one function call together with a variable assignment
The script "checkpatch.pl" pointed information out like the following.
ERROR: do not use assignment in if condition
Thus fix the affected source code place.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Jens Axboe <axboe@fb.com>
Alexander Potapenko [Mon, 23 Jan 2017 14:06:43 +0000 (15:06 +0100)]
block: Initialize cfqq->ioprio_class in cfq_get_queue()
KMSAN (KernelMemorySanitizer, a new error detection tool) reports use of
uninitialized memory in cfq_init_cfqq():
==================================================================
BUG: KMSAN: use of unitialized memory
...
Call Trace:
[< inline >] __dump_stack lib/dump_stack.c:15
[<
ffffffff8202ac97>] dump_stack+0x157/0x1d0 lib/dump_stack.c:51
[<
ffffffff813e9b65>] kmsan_report+0x205/0x360 ??:?
[<
ffffffff813eabbb>] __msan_warning+0x5b/0xb0 ??:?
[< inline >] cfq_init_cfqq block/cfq-iosched.c:3754
[<
ffffffff8201e110>] cfq_get_queue+0xc80/0x14d0 block/cfq-iosched.c:3857
...
origin:
[<
ffffffff8103ab37>] save_stack_trace+0x27/0x50 arch/x86/kernel/stacktrace.c:67
[<
ffffffff813e836b>] kmsan_internal_poison_shadow+0xab/0x150 ??:?
[<
ffffffff813e88ab>] kmsan_poison_slab+0xbb/0x120 ??:?
[< inline >] allocate_slab mm/slub.c:1627
[<
ffffffff813e533f>] new_slab+0x3af/0x4b0 mm/slub.c:1641
[< inline >] new_slab_objects mm/slub.c:2407
[<
ffffffff813e0ef3>] ___slab_alloc+0x323/0x4a0 mm/slub.c:2564
[< inline >] __slab_alloc mm/slub.c:2606
[< inline >] slab_alloc_node mm/slub.c:2669
[<
ffffffff813dfb42>] kmem_cache_alloc_node+0x1d2/0x1f0 mm/slub.c:2746
[<
ffffffff8201d90d>] cfq_get_queue+0x47d/0x14d0 block/cfq-iosched.c:3850
...
==================================================================
(the line numbers are relative to 4.8-rc6, but the bug persists
upstream)
The uninitialized struct cfq_queue is created by kmem_cache_alloc_node()
and then passed to cfq_init_cfqq(), which accesses cfqq->ioprio_class
before it's initialized.
Signed-off-by: Alexander Potapenko <glider@google.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Jan Kara [Tue, 28 Jun 2016 07:04:02 +0000 (09:04 +0200)]
cfq-iosched: Charge at least 1 jiffie instead of 1 ns
Commit
9a7f38c42c2b (cfq-iosched: Convert from jiffies to nanoseconds)
could result in charging just 1 ns to a cgroup submitting IO instead of 1
jiffie we always charged before. It is arguable what is the right amount
to change but for now lets retain the old behavior of always charging at
least one jiffie.
Fixes:
9a7f38c42c2b92391d9dabaf9f51df7cfe5608e4
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Jens Axboe <axboe@fb.com>
Jan Kara [Tue, 28 Jun 2016 07:04:01 +0000 (09:04 +0200)]
cfq-iosched: Fix regression in bonnie++ rewrite performance
Commit
9a7f38c42c2 (cfq-iosched: Convert from jiffies to nanoseconds)
broke the condition for detecting starved sync IO in
cfq_completed_request() because rq->start_time remained in jiffies but
we compared it with nanosecond values. This manifested as a regression
in bonnie++ rewrite performance because we always ended up considering
sync IO starved and thus never increased async IO queue depth.
Since rq->start_time is used in a lot of places, converting it to ns
values would be non-trivial. So just revert the condition in CFQ to use
comparison with jiffies. This will lead to suboptimal results if
cfq_fifo_expire[1] will ever come close to 1 jiffie but so far we are
relatively far from that with the storage used with CFQ (the default
value is 128 ms).
Fixes:
9a7f38c42c2b92391d9dabaf9f51df7cfe5608e4
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Jens Axboe <axboe@fb.com>
Jan Kara [Tue, 28 Jun 2016 07:04:00 +0000 (09:04 +0200)]
cfq-iosched: Convert slice_resid from u64 to s64
slice_resid can be both positive and negative. Commit
9a7f38c42c2b
(cfq-iosched: Convert from jiffies to nanoseconds) converted it from
long to u64. Although this did not introduce any functional regression
(the operations just overflow and the result was fine), it is certainly
wrong and could cause issues in future. So convert the type to more
appropriate s64.
Fixes:
9a7f38c42c2b92391d9dabaf9f51df7cfe5608e4
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Jens Axboe <axboe@fb.com>
Jan Kara [Wed, 8 Jun 2016 13:11:39 +0000 (15:11 +0200)]
cfq-iosched: Convert to use highres timers
Reviewed-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Jan Kara <jack@suse.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Jeff Moyer [Wed, 8 Jun 2016 13:11:38 +0000 (15:11 +0200)]
cfq-iosched: Expose microsecond interfaces
Expose interfaces to tune time slices of CFQ IO scheduler in
microseconds.
Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Jens Axboe <axboe@fb.com>
Jeff Moyer [Wed, 8 Jun 2016 14:55:34 +0000 (08:55 -0600)]
cfq-iosched: Convert from jiffies to nanoseconds
Convert all time-keeping in CFQ IO scheduler from jiffies to nanoseconds
so that we can later make the intervals more fine-grained than jiffies.
One jiffie is several miliseconds and even for today's rotating disks
that is a noticeable amount of time and thus we leave disk unnecessarily
idle.
Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Jens Axboe <axboe@fb.com>
[wight554: fix backport conflict]
Signed-off-by: Volodymyr Zhdanov <wight554@gmail.com>
Jan Kara [Tue, 12 Jan 2016 15:24:19 +0000 (16:24 +0100)]
cfq-iosched: Allow parent cgroup to preempt its child
Currently we don't allow sync workload of one cgroup to preempt sync
workload of any other cgroup. This is because we want to achieve service
separation between cgroups. However in cases where cgroup preempting is
ancestor of the current cgroup, there is no need of separation and
idling introduces unnecessary overhead. This hurts for example the case
when workload is isolated within a cgroup but journalling threads are in
root cgroup. Simple way to demostrate the issue is using:
dbench4 -c /usr/share/dbench4/client.txt -t 10 -D /mnt 1
on ext4 filesystem on plain SATA drive (mounted with barrier=0 to make
difference more visible). When all processes are in the root cgroup,
reported throughput is 153.132 MB/sec. When dbench process gets its own
blkio cgroup, reported throughput drops to 26.1006 MB/sec.
Fix the problem by making check in cfq_should_preempt() more benevolent
and allow preemption by ancestor cgroup. This improves the throughput
reported by dbench4 to 48.9106 MB/sec.
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Jan Kara <jack@suse.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Jan Kara [Tue, 12 Jan 2016 15:24:17 +0000 (16:24 +0100)]
cfq-iosched: Allow sync noidle workloads to preempt each other
The original idea with preemption of sync noidle queues (introduced in
commit
718eee0579b8 "cfq-iosched: fairness for sync no-idle queues") was
that we service all sync noidle queues together, we don't idle on any of
the queues individually and we idle only if there is no sync noidle
queue to be served. This intention also matches the original test:
if (cfqd->serving_type == SYNC_NOIDLE_WORKLOAD
&& new_cfqq->service_tree == cfqq->service_tree)
return true;
However since at that time cfqq->service_tree was not set for idling
queues, this test was unreliable and was replaced in commit
e4a229196a7c
"cfq-iosched: fix no-idle preemption logic" by:
if (cfqd->serving_type == SYNC_NOIDLE_WORKLOAD &&
cfqq_type(new_cfqq) == SYNC_NOIDLE_WORKLOAD &&
new_cfqq->service_tree->count == 1)
return true;
That was a reliable test but was actually doing something different -
now we preempt sync noidle queue only if the new queue is the only one
busy in the service tree.
These days cfq queue is kept in service tree even if it is idling and
thus the original check would be safe again. But since we actually check
that cfq queues are in the same cgroup, of the same priority class and
workload type (sync noidle), we know that new_cfqq is fine to preempt
cfqq. So just remove the service tree check.
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Jan Kara <jack@suse.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Jan Kara [Tue, 12 Jan 2016 15:24:16 +0000 (16:24 +0100)]
cfq-iosched: Reorder checks in cfq_should_preempt()
Move check for preemption by rt class up. There is no functional change
but it makes arguing about conditions simpler since we can be sure both
cfq queues are from the same ioprio class.
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Jan Kara <jack@suse.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Park Ju Hyung [Tue, 26 Sep 2017 01:51:24 +0000 (10:51 +0900)]
f2fs: set ioprio of GC kthread to idle
GC should run conservatively as possible to reduce latency spikes to the user.
Setting ioprio to idle class will allow the kernel to schedule GC thread's I/O
to not affect any other processes' I/O requests.
Signed-off-by: Park Ju Hyung <qkrwngud825@gmail.com>
wloot [Wed, 10 Apr 2019 19:29:10 +0000 (03:29 +0800)]
gpu: kgsl: Make max_gpuclk no op
Tyler Nijmeh [Sun, 14 Oct 2018 18:17:44 +0000 (11:17 -0700)]
cpuidle: Make MENU cpuidle governor optional
Qualcomm devices actually use LPM-based governors (QCOM), therefore this
is a useless driver to have.
Signed-off-by: Tyler Nijmeh <tylernij@gmail.com>
wloot [Thu, 2 May 2019 15:04:36 +0000 (23:04 +0800)]
zram: Set default compressor to lz4
Park Ju Hyung [Sat, 13 Apr 2019 10:00:11 +0000 (19:00 +0900)]
dsp: asm: improve misleading logs
On case ASM_STREAM_CMD_OPEN_WRITE_COMPRESSED, payload size error log
might be shown when it's actually correct due to (payload[1] != 0)
check failing. Fix this.
Also, add missing new line and change size error logs to debug type
if checks are done solely to print debug messages.
Commit
979f3d57b439 ("dsp: asm: validate payload size before access")
introduced these payload size check logs.
Signed-off-by: Park Ju Hyung <qkrwngud825@gmail.com>
Park Ju Hyung [Wed, 3 Apr 2019 04:23:31 +0000 (13:23 +0900)]
writeback: hardcode dirty_expire_centisecs=3000 (30s)
https://android-review.googlesource.com/c/platform/system/core/+/938362
Hardcode this and make /proc/sys/vm/dirty_expire_centisecs a no-op.
Signed-off-by: Park Ju Hyung <qkrwngud825@gmail.com>
Jackie Liu [Tue, 4 Dec 2018 01:43:23 +0000 (09:43 +0800)]
arm64: crypto: add NEON accelerated XOR implementation
This is a NEON acceleration method that can improve
performance by approximately 20%. I got the following
data from the centos 7.5 on Huawei's HISI1616 chip:
[ 93.837726] xor: measuring software checksum speed
[ 93.874039] 8regs : 7123.200 MB/sec
[ 93.914038] 32regs : 7180.300 MB/sec
[ 93.954043] arm64_neon: 9856.000 MB/sec
[ 93.954047] xor: using function: arm64_neon (9856.000 MB/sec)
I believe this code can bring some optimization for
all arm64 platform. thanks for Ard Biesheuvel's suggestions.
Signed-off-by: Jackie Liu <liuyun01@kylinos.cn>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Park Ju Hyung [Wed, 13 Mar 2019 05:08:35 +0000 (14:08 +0900)]
arm64: crc32: always assume ARM64_HAS_CRC32
Our alternative framework is not ready for this.
Just hardcode this in.
Signed-off-by: Park Ju Hyung <qkrwngud825@gmail.com>
Miguel Ojeda [Thu, 24 Jan 2019 14:59:11 +0000 (15:59 +0100)]
lib/crc32.c: mark crc32_le_base/__crc32c_le_base aliases as __pure
The upcoming GCC 9 release extends the -Wmissing-attributes warnings
(enabled by -Wall) to C and aliases: it warns when particular function
attributes are missing in the aliases but not in their target.
In particular, it triggers here because crc32_le_base/__crc32c_le_base
aren't __pure while their target crc32_le/__crc32c_le are.
These aliases are used by architectures as a fallback in accelerated
versions of CRC32. See commit
9784d82db3eb ("lib/crc32: make core crc32()
routines weak so they can be overridden").
Therefore, being fallbacks, it is likely that even if the aliases
were called from C, there wouldn't be any optimizations possible.
Currently, the only user is arm64, which calls this from asm.
Still, marking the aliases as __pure makes sense and is a good idea
for documentation purposes and possible future optimizations,
which also silences the warning.
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Laura Abbott <labbott@redhat.com>
Signed-off-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Ard Biesheuvel [Mon, 27 Aug 2018 11:02:42 +0000 (13:02 +0200)]
lib/crc32: make core crc32() routines weak so they can be overridden
Allow architectures to drop in accelerated CRC32 routines by making
the crc32_le/__crc32c_le entry points weak, and exposing non-weak
aliases for them that may be used by the accelerated versions as
fallbacks in case the instructions they rely upon are not available.
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Ard Biesheuvel [Tue, 27 Nov 2018 17:42:55 +0000 (18:42 +0100)]
arm64/lib: improve CRC32 performance for deep pipelines
Improve the performance of the crc32() asm routines by getting rid of
most of the branches and small sized loads on the common path.
Instead, use a branchless code path involving overlapping 16 byte
loads to process the first (length % 32) bytes, and process the
remainder using a loop that processes 32 bytes at a time.
Tested using the following test program:
#include <stdlib.h>
extern void crc32_le(unsigned short, char const*, int);
int main(void)
{
static const char buf[4096];
srand(
20181126);
for (int i = 0; i < 100 * 1000 * 1000; i++)
crc32_le(0, buf, rand() % 1024);
return 0;
}
On Cortex-A53 and Cortex-A57, the performance regresses but only very
slightly. On Cortex-A72 however, the performance improves from
$ time ./crc32
real 0m10.149s
user 0m10.149s
sys 0m0.000s
to
$ time ./crc32
real 0m7.915s
user 0m7.915s
sys 0m0.000s
Cc: Rui Sun <sunrui26@huawei.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Ard Biesheuvel [Mon, 27 Aug 2018 11:02:44 +0000 (13:02 +0200)]
arm64/lib: add accelerated crc32 routines
Unlike crc32c(), which is wired up to the crypto API internally so the
optimal driver is selected based on the platform's capabilities,
crc32_le() is implemented as a library function using a slice-by-8 table
based C implementation. Even though few of the call sites may be
bottlenecks, calling a time variant implementation with a non-negligible
D-cache footprint is a bit of a waste, given that ARMv8.1 and up mandates
support for the CRC32 instructions that were optional in ARMv8.0, but are
already widely available, even on the Cortex-A53 based Raspberry Pi.
So implement routines that use these instructions if available, and fall
back to the existing generic routines otherwise. The selection is based
on alternatives patching.
Note that this unconditionally selects CONFIG_CRC32 as a builtin. Since
CRC32 is relied upon by core functionality such as CONFIG_OF_FLATTREE,
this just codifies the status quo.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Mark Rutland [Fri, 27 Apr 2018 10:50:36 +0000 (11:50 +0100)]
arm64: avoid instrumenting atomic_ll_sc.o
Our out-of-line atomics are built with a special calling convention,
preventing pointless stack spilling, and allowing us to patch call sites
with ARMv8.1 atomic instructions.
Instrumentation inserted by the compiler may result in calls to
functions not following this special calling convention, resulting in
registers being unexpectedly clobbered, and various problems resulting
from this.
For example, if a kernel is built with KCOV and ARM64_LSE_ATOMICS, the
compiler inserts calls to __sanitizer_cov_trace_pc in the prologues of
the atomic functions. This has been observed to result in spurious
cmpxchg failures, leading to a hang early on in the boot process.
This patch avoids such issues by preventing instrumentation of our
out-of-line atomics.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Will Deacon [Fri, 9 Feb 2018 13:19:47 +0000 (13:19 +0000)]
arm64: lse: Pass -fomit-frame-pointer to out-of-line ll/sc atomics
In cases where x30 is used as a temporary in the out-of-line ll/sc atomics
(e.g. atomic_fetch_add), the compiler tends to put out a full stackframe,
which included pointing the x29 at the new frame.
Since these things aren't traceable anyway, we can pass -fomit-frame-pointer
to reduce the work when spilling. Since this is incompatible with -pg, we
also remove that from the CFLAGS for this file.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Jason A. Donenfeld [Tue, 7 Nov 2017 02:24:04 +0000 (11:24 +0900)]
arm64: make label allocation style consistent in tishift
This is entirely cosmetic, but somehow it was missed when sending
differing versions of this patch. This just makes the file a bit more
uniform.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Jason A. Donenfeld [Tue, 7 Nov 2017 01:49:54 +0000 (01:49 +0000)]
arm64: Implement __lshrti3 library function
Commit
fb8722735f50 ("arm64: support __int128 on gcc 5+") added support
for the __int128 data type, but this breaks the build in some configurations
where GCC ends up emitting calls to the __lshrti3 helper in libgcc, which
results in a link error:
kernel/sched/fair.o: In function `__calc_delta':
fair.c:(.text+0xca0): undefined reference to `__lshrti3'
kernel/time/timekeeping.o: In function `timekeeping_resume':
timekeeping.c:(.text+0x3f60): undefined reference to `__lshrti3'
make: *** [vmlinux] Error 1
Fix the build by providing an implementation of __lshrti3, like we do
already for __ashlti3 and __ashrti3.
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Jason A. Donenfeld [Fri, 3 Nov 2017 14:18:58 +0000 (15:18 +0100)]
arm64: support __int128 on gcc 5+
Versions of gcc prior to gcc 5 emitted a __multi3 function call when
dealing with TI types, resulting in failures when trying to link to
libgcc, and more generally, bad performance. However, since gcc 5,
the compiler supports actually emitting fast instructions, which means
we can at long last enable this option and receive the speedups.
The gcc commit that added proper Aarch64 support is:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=
d1ae7bb994f49316f6f63e6173f2931e837a351d
This commit appears to be part of the gcc 5 release.
There are still a few instructions, __ashlti3 and __ashrti3, which
require libgcc, which is fine. Rather than linking to libgcc, we
simply provide them ourselves, since they're not that complicated.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Julien Thierry [Fri, 13 Oct 2017 13:32:56 +0000 (14:32 +0100)]
arm64: use WFE for long delays
The current delay implementation uses the yield instruction, which is a
hint that it is beneficial to schedule another thread. As this is a hint,
it may be implemented as a NOP, causing all delays to be busy loops. This
is the case for many existing CPUs.
Taking advantage of the generic timer sending periodic events to all
cores, we can use WFE during delays to reduce power consumption. This is
beneficial only for delays longer than the period of the timer event
stream.
If timer event stream is not enabled, delays will behave as yield/busy
loops.
Signed-off-by: Julien Thierry <julien.thierry@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Julien Thierry [Fri, 13 Oct 2017 13:32:55 +0000 (14:32 +0100)]
arm_arch_timer: Expose event stream status
The arch timer configuration for a CPU might get reset after suspending
said CPU.
In order to reliably use the event stream in the kernel (e.g. for delays),
we keep track of the state where we can safely consider the event stream as
properly configured. After writing to cntkctl, we issue an ISB to ensure
that subsequent delay loops can rely on the event stream being enabled.
Signed-off-by: Julien Thierry <julien.thierry@arm.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Marc Zyngier [Tue, 4 Apr 2017 16:05:16 +0000 (17:05 +0100)]
arm64: arch_timer: Save cntkctl_el1 as a per-cpu variable
As we're about to allow per CPU cntkctl_el1 configuration, we cannot
rely on the register value to be common when performing power
management.
Let's turn saved_cntkctl into a per-cpu variable.
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Park Ju Hyung [Wed, 13 Mar 2019 02:30:02 +0000 (11:30 +0900)]
Revert "PM / Suspend: Print wall time at suspend entry and exit"
This reverts commit
b9acbfee678bf41939a9b0bbe09281e53f8ac11a.
This is an expensive logging and not all that useful as it could get skewed.
Signed-off-by: Park Ju Hyung <qkrwngud825@gmail.com>
Park Ju Hyung [Fri, 8 Mar 2019 14:02:21 +0000 (23:02 +0900)]
blk: disable IO_STAT completely
Signed-off-by: Park Ju Hyung <qkrwngud825@gmail.com>
kdrag0n [Sun, 23 Dec 2018 06:36:19 +0000 (22:36 -0800)]
block: disable I/O stats accounting by default
While Android userspace (e.g. storaged) does use iostats via
/proc/diskstats, init will explicitly enable iostats for the devices on
which it is primarily used - sda and sdf. Avoid the 0.5-1% overhead for
block devices that do not need it.
Signed-off-by: kdrag0n <dragon@khronodragon.com>
Davidlohr Bueso [Fri, 8 Sep 2017 23:14:36 +0000 (16:14 -0700)]
rbtree: cache leftmost node internally
Commit
cd9e61ed1eebbcd5dfad59475d41ec58d9b64b6a upstream.
Patch series "rbtree: Cache leftmost node internally", v4.
A series to extending rbtrees to internally cache the leftmost node such
that we can have fast overlap check optimization for all interval tree
users[1]. The benefits of this series are that:
(i) Unify users that do internal leftmost node caching.
(ii) Optimize all interval tree users.
(iii) Convert at least two new users (epoll and procfs) to the new interface.
This patch (of 16):
Red-black tree semantics imply that nodes with smaller or greater (or
equal for duplicates) keys always be to the left and right,
respectively. For the kernel this is extremely evident when considering
our rb_first() semantics. Enabling lookups for the smallest node in the
tree in O(1) can save a good chunk of cycles in not having to walk down
the tree each time. To this end there are a few core users that
explicitly do this, such as the scheduler and rtmutexes. There is also
the desire for interval trees to have this optimization allowing faster
overlap checking.
This patch introduces a new 'struct rb_root_cached' which is just the
root with a cached pointer to the leftmost node. The reason why the
regular rb_root was not extended instead of adding a new structure was
that this allows the user to have the choice between memory footprint
and actual tree performance. The new wrappers on top of the regular
rb_root calls are:
- rb_first_cached(cached_root) -- which is a fast replacement
for rb_first.
- rb_insert_color_cached(node, cached_root, new)
- rb_erase_cached(node, cached_root)
In addition, augmented cached interfaces are also added for basic
insertion and deletion operations; which becomes important for the
interval tree changes.
With the exception of the inserts, which adds a bool for updating the
new leftmost, the interfaces are kept the same. To this end, porting rb
users to the cached version becomes really trivial, and keeping current
rbtree semantics for users that don't care about the optimization
requires zero overhead.
Change-Id: I17f7605dfc2f797f6a5ec24693871ffb89505de6
Link: http://lkml.kernel.org/r/20170719014603.19029-2-dave@stgolabs.net
Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
Reviewed-by: Jan Kara <jack@suse.cz>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Harsh Shandilya <harsh@prjkt.io>
Signed-off-by: mydongistiny <jaysonedson@gmail.com>
Signed-off-by: kdrag0n <dragon@khronodragon.com>
kdrag0n [Thu, 27 Sep 2018 00:21:12 +0000 (17:21 -0700)]
mm: swap: swap pages one at a time
According to Google, this is optimal.
"By default, the Linux kernel swaps in 8 pages of memory at a time. When
using ZRAM, the incremental cost of reading 1 page at a time is
negligible and may help in case the device is under extreme memory
pressure."
Source: https://source.android.com/devices/tech/perf/low-ram
Signed-off-by: kdrag0n <dragon@khronodragon.com>
Davidlohr Bueso [Fri, 8 Sep 2017 23:14:42 +0000 (16:14 -0700)]
rbtree: add some additional comments for rebalancing cases
While overall the code is very nicely commented, it might not be
immediately obvious from the diagrams what is going on. Add a very
brief summary of each case. Opposite cases where the node is the left
child are left untouched.
Link: http://lkml.kernel.org/r/20170719014603.19029-4-dave@stgolabs.net
Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit
35dc67d7d922b2c9a1adb006c7a0f370eeb5c114)
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: khusika <khusikadhamar@gmail.com>
Signed-off-by: kdrag0n <dragon@khronodragon.com>
Davidlohr Bueso [Fri, 8 Sep 2017 23:14:39 +0000 (16:14 -0700)]
rbtree: optimize root-check during rebalancing loop
The only times the nil-parent (root node) condition is true is when the
node is the first in the tree, or after fixing rbtree rule #4 and the
case 1 rebalancing made the node the root. Such conditions do not apply
most of the time:
(i) The common case in an rbtree is to have more than a single node,
so this is only true for the first rb_insert().
(ii) While there is a chance only one first rotation is needed, cases
where the node's uncle is black (cases 2,3) are more common as we can
have the following scenarios during the rotation looping:
case1 only, case1+1, case2+3, case1+2+3, case3 only, etc.
This patch, therefore, adds an unlikely() optimization to this
conditional. When profiling with CONFIG_PROFILE_ANNOTATED_BRANCHES, a
kernel build shows that the incorrect rate is less than 15%, and for
workloads that involve insert mostly trees overtime tend to have less
than 2% incorrect rate.
Link: http://lkml.kernel.org/r/20170719014603.19029-3-dave@stgolabs.net
Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit
2aadf7fc7df9e70c99786ffb8452ccdd83d49e59)
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: khusika <khusikadhamar@gmail.com>
Signed-off-by: kdrag0n <dragon@khronodragon.com>
Gaurav Jindal [Thu, 14 Jul 2016 12:04:20 +0000 (12:04 +0000)]
tick/nohz: Optimize nohz idle enter
tick_nohz_start_idle is called before checking whether the idle tick can be
stopped. If the tick cannot be stopped, calling tick_nohz_start_idle() is
pointless and just wasting CPU cycles.
Only invoke tick_nohz_start_idle() when can_stop_idle_tick() returns true. A
short one minute observation of the effect on ARM64 shows a reduction of calls
by 1.5% thus optimizing the idle entry sequence.
[tglx: Massaged changelog ]
Co-developed-by: Sanjeev Yadav<sanjeev.yadav@spreadtrum.com>
Signed-off-by: Gaurav Jindal<gaurav.jindal@spreadtrum.com>
Link: http://lkml.kernel.org/r/20160714120416.GB21099@gaurav.jindal@spreadtrum.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
Signed-off-by: kdrag0n <dragon@khronodragon.com>
Eric Dumazet [Tue, 16 May 2017 21:00:11 +0000 (14:00 -0700)]
tcp_westwood: use tcp_jiffies32 instead of tcp_time_stamp
This CC does not need 1 ms tcp_time_stamp and can use
the jiffy based 'timestamp'.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: ahmedradaideh <ahmed.radaideh@gmail.com>
Signed-off-by: Yaroslav Furman <yaro330@gmail.com>
Signed-off-by: celtare21 <celtare21@gmail.com>
Signed-off-by: kdrag0n <dragon@khronodragon.com>
Eric Dumazet [Tue, 16 May 2017 21:00:01 +0000 (14:00 -0700)]
tcp: introduce tcp_jiffies32
We abuse tcp_time_stamp for two different cases :
1) base to generate TCP Timestamp options (RFC 7323)
2) A 32bit version of jiffies since some TCP fields
are 32bit wide to save memory.
Since we want in the future to have 1ms TCP TS clock,
regardless of HZ value, we want to cleanup things.
tcp_jiffies32 is the truncated jiffies value,
which will be used only in places where we want a 'host'
timestamp.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: ahmedradaideh <ahmed.radaideh@gmail.com>
Signed-off-by: celtare21 <celtare21@gmail.com>
Signed-off-by: kdrag0n <dragon@khronodragon.com>
Arnd Bergmann [Tue, 10 Jul 2018 15:16:27 +0000 (17:16 +0200)]
arm64: make flatmem depend on !NUMA
Building without NUMA but with FLATMEM results in a link error
because mem_map[] is not available:
aarch64-linux-ld -EB -maarch64elfb --no-undefined -X -pie -shared -Bsymbolic --no-apply-dynamic-relocs --build-id -o .tmp_vmlinux1 -T ./arch/arm64/kernel/vmlinux.lds --whole-archive built-in.a --no-whole-archive --start-group arch/arm64/lib/lib.a lib/lib.a --end-group
init/do_mounts.o: In function `mount_block_root':
do_mounts.c:(.init.text+0x1e8): undefined reference to `mem_map'
arch/arm64/kernel/vdso.o: In function `vdso_init':
vdso.c:(.init.text+0xb4): undefined reference to `mem_map'
This uses the same trick as the other architectures, making flatmem
depend on !NUMA to avoid the broken configuration.
Fixes:
e7d4bac428ed ("arm64: add ARM64-specific support for flatmem")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: kdrag0n <dragon@khronodragon.com>
Nikunj Kela [Fri, 6 Jul 2018 17:47:24 +0000 (10:47 -0700)]
arm64: add ARM64-specific support for flatmem
Flatmem is useful in reducing kernel memory usage.
One usecase is in kdump kernel. We are able to save
~14M by moving to flatmem scheme.
Cc: xe-kernel@external.cisco.com
Cc: Nikunj Kela <nkela@cisco.com>
Signed-off-by: Nikunj Kela <nkela@cisco.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: kdrag0n <dragon@khronodragon.com>
Arnd Bergmann [Mon, 15 Jan 2018 16:07:22 +0000 (17:07 +0100)]
crypto: aes-generic - fix aes-generic regression on powerpc
My last bugfix added -Os on the command line, which unfortunately caused
a build regression on powerpc in some configurations.
I've done some more analysis of the original problem and found slightly
different workaround that avoids this regression and also results in
better performance on gcc-7.0: -fcode-hoisting is an optimization step
that got added in gcc-7 and that for all gcc-7 versions causes worse
performance.
This disables -fcode-hoisting on all compilers that understand the option.
For gcc-7.1 and 7.2 I found the same performance as my previous patch
(using -Os), in gcc-7.0 it was even better. On gcc-8 I could see no
change in performance from this patch. In theory, code hoisting should
not be able make things better for the AES cipher, so leaving it
disabled for gcc-8 only serves to simplify the Makefile change.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Link: https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg30418.html
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83356
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83651
Fixes:
148b974deea9 ("crypto: aes-generic - build with -Os on gcc-7+")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Arnd Bergmann [Wed, 3 Jan 2018 22:39:27 +0000 (23:39 +0100)]
crypto: aes-generic - build with -Os on gcc-7+
While testing other changes, I discovered that gcc-7.2.1 produces badly
optimized code for aes_encrypt/aes_decrypt. This is especially true when
CONFIG_UBSAN_SANITIZE_ALL is enabled, where it leads to extremely
large stack usage that in turn might cause kernel stack overflows:
crypto/aes_generic.c: In function 'aes_encrypt':
crypto/aes_generic.c:1371:1: warning: the frame size of 4880 bytes is larger than 2048 bytes [-Wframe-larger-than=]
crypto/aes_generic.c: In function 'aes_decrypt':
crypto/aes_generic.c:1441:1: warning: the frame size of 4864 bytes is larger than 2048 bytes [-Wframe-larger-than=]
I verified that this problem exists on all architectures that are
supported by gcc-7.2, though arm64 in particular is less affected than
the others. I also found that gcc-7.1 and gcc-8 do not show the extreme
stack usage but still produce worse code than earlier versions for this
file, apparently because of optimization passes that generally provide
a substantial improvement in object code quality but understandably fail
to find any shortcuts in the AES algorithm.
Possible workarounds include
a) disabling -ftree-pre and -ftree-sra optimizations, this was an earlier
patch I tried, which reliably fixed the stack usage, but caused a
serious performance regression in some versions, as later testing
found.
b) disabling UBSAN on this file or all ciphers, as suggested by Ard
Biesheuvel. This would lead to massively better crypto performance in
UBSAN-enabled kernels and avoid the stack usage, but there is a concern
over whether we should exclude arbitrary files from UBSAN at all.
c) Forcing the optimization level in a different way. Similar to a),
but rather than deselecting specific optimization stages,
this now uses "gcc -Os" for this file, regardless of the
CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE/SIZE option. This is a reliable
workaround for the stack consumption on all architecture, and I've
retested the performance results now on x86, cycles/byte (lower is
better) for cbc(aes-generic) with 256 bit keys:
-O2 -Os
gcc-6.3.1 14.9 15.1
gcc-7.0.1 14.7 15.3
gcc-7.1.1 15.3 14.7
gcc-7.2.1 16.8 15.9
gcc-8.0.0 15.5 15.6
This implements the option c) by enabling forcing -Os on all compiler
versions starting with gcc-7.1. As a workaround for PR83356, it would
only be needed for gcc-7.2+ with UBSAN enabled, but since it also shows
better performance on gcc-7.1 without UBSAN, it seems appropriate to
use the faster version here as well.
Side note: during testing, I also played with the AES code in libressl,
which had a similar performance regression from gcc-6 to gcc-7.2,
but was three times slower overall. It might be interesting to
investigate that further and possibly port the Linux implementation
into that.
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83356
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83651
Cc: Richard Biener <rguenther@suse.de>
Cc: Jakub Jelinek <jakub@gcc.gnu.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Arjan van de Ven [Sat, 29 Apr 2017 22:24:34 +0000 (22:24 +0000)]
kernel: time: reduce ntp wakeups
Signed-off-by: Park Ju Hyung <qkrwngud825@gmail.com>
Gao Xiang [Tue, 30 Oct 2018 22:07:28 +0000 (15:07 -0700)]
lib/lz4: update LZ4 decompressor module
Update the LZ4 compression module based on LZ4 v1.8.3 in order for the
erofs file system to use the newest LZ4_decompress_safe_partial() which
can now decode exactly the nb of bytes requested [1] to take place of the
open hacked code in the erofs file system itself.
Currently, apart from the erofs file system, no other users use
LZ4_decompress_safe_partial, so no worry about the interface.
In addition, LZ4 v1.8.x boosts up decompression speed compared to the
current code which is based on LZ4 v1.7.3, mainly due to shortcut
optimization for the specific common LZ4-sequences [2].
lzbench testdata (tested in kirin710, 8 cores, 4 big cores
at 2189Mhz, 2GB DDR RAM at 1622Mhz, with enwik8 testdata [3]):
Compressor name Compress. Decompress. Compr. size Ratio Filename
memcpy 5004 MB/s 4924 MB/s
100000000 100.00 enwik8
lz4hc 1.7.3 -9 12 MB/s 653 MB/s
42203253 42.20 enwik8
lz4hc 1.8.0 -9 12 MB/s 908 MB/s
42203096 42.20 enwik8
lz4hc 1.8.3 -9 11 MB/s 965 MB/s
42203094 42.20 enwik8
[1] https://github.com/lz4/lz4/issues/566
https://github.com/lz4/lz4/commit/
08d347b5b217b011ff7487130b79480d8cfdaeb8
[2] v1.8.1 perf: slightly faster compression and decompression speed
https://github.com/lz4/lz4/commit/
a31b7058cb97e4393da55e78a77a1c6f0c9ae038
v1.8.2 perf: slightly faster HC compression and decompression speed
https://github.com/lz4/lz4/commit/
45f8603aae389d34c689d3ff7427b314071ccd2c
https://github.com/lz4/lz4/commit/
1a191b3f8d26b50a7c1d41590b529ec308d768cd
[3] http://mattmahoney.net/dc/textdata.html
http://mattmahoney.net/dc/enwik8.zip
Link: http://lkml.kernel.org/r/1537181207-21932-1-git-send-email-gaoxiang25@huawei.com
Signed-off-by: Gao Xiang <gaoxiang25@huawei.com>
Tested-by: Guo Xuenan <guoxuenan@huawei.com>
Cc: Colin Ian King <colin.king@canonical.com>
Cc: Yann Collet <yann.collet.73@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Fang Wei <fangwei1@huawei.com>
Cc: Chao Yu <yuchao0@huawei.com>
Cc: Miao Xie <miaoxie@huawei.com>
Cc: Sven Schmidt <4sschmid@informatik.uni-hamburg.de>
Cc: Kyungsik Lee <kyungsik.lee@lge.com>
Cc: <weidu.du@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Colin Ian King [Tue, 3 Oct 2017 23:16:01 +0000 (16:16 -0700)]
lib/lz4: make arrays static const, reduces object code size
Don't populate the read-only arrays dec32table and dec64table on the
stack, instead make them both static const. Makes the object code
smaller by over 10K bytes:
Before:
text data bss dec hex filename
31500 0 0 31500 7b0c lib/lz4/lz4_decompress.o
After:
text data bss dec hex filename
20237 176 0 20413 4fbd lib/lz4/lz4_decompress.o
(gcc version 7.2.0 x86_64)
Link: http://lkml.kernel.org/r/20170921221939.20820-1-colin.king@canonical.com
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Cc: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Cc: Sven Schmidt <4sschmid@informatik.uni-hamburg.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Joe Perches <joe@perches.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Sven Schmidt [Fri, 24 Feb 2017 23:01:25 +0000 (15:01 -0800)]
lib/lz4: remove back-compat wrappers
Remove the functions introduced as wrappers for providing backwards
compatibility to the prior LZ4 version. They're not needed anymore
since there's no callers left.
Link: http://lkml.kernel.org/r/1486321748-19085-6-git-send-email-4sschmid@informatik.uni-hamburg.de
Signed-off-by: Sven Schmidt <4sschmid@informatik.uni-hamburg.de>
Cc: Bongkyu Kim <bongkyu.kim@lge.com>
Cc: Rui Salvaterra <rsalvaterra@gmail.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: David S. Miller <davem@davemloft.net>
Cc: Anton Vorontsov <anton@enomsg.org>
Cc: Colin Cross <ccross@android.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Tony Luck <tony.luck@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Sven Schmidt [Fri, 24 Feb 2017 23:01:19 +0000 (15:01 -0800)]
crypto: change LZ4 modules to work with new LZ4 module version
Update the crypto modules using LZ4 compression as well as the test
cases in testmgr.h to work with the new LZ4 module version.
Link: http://lkml.kernel.org/r/1486321748-19085-4-git-send-email-4sschmid@informatik.uni-hamburg.de
Signed-off-by: Sven Schmidt <4sschmid@informatik.uni-hamburg.de>
Cc: Bongkyu Kim <bongkyu.kim@lge.com>
Cc: Rui Salvaterra <rsalvaterra@gmail.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: David S. Miller <davem@davemloft.net>
Cc: Anton Vorontsov <anton@enomsg.org>
Cc: Colin Cross <ccross@android.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Tony Luck <tony.luck@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Sven Schmidt [Fri, 24 Feb 2017 23:01:16 +0000 (15:01 -0800)]
lib/decompress_unlz4: change module to work with new LZ4 module version
Update the unlz4 wrapper to work with the updated LZ4 kernel module
version.
Link: http://lkml.kernel.org/r/1486321748-19085-3-git-send-email-4sschmid@informatik.uni-hamburg.de
Signed-off-by: Sven Schmidt <4sschmid@informatik.uni-hamburg.de>
Cc: Bongkyu Kim <bongkyu.kim@lge.com>
Cc: Rui Salvaterra <rsalvaterra@gmail.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: David S. Miller <davem@davemloft.net>
Cc: Anton Vorontsov <anton@enomsg.org>
Cc: Colin Cross <ccross@android.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Tony Luck <tony.luck@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Sven Schmidt [Fri, 24 Feb 2017 23:01:12 +0000 (15:01 -0800)]
lib: update LZ4 compressor module
Patch series "Update LZ4 compressor module", v7.
This patchset updates the LZ4 compression module to a version based on
LZ4 v1.7.3 allowing to use the fast compression algorithm aka LZ4 fast
which provides an "acceleration" parameter as a tradeoff between high
compression ratio and high compression speed.
We want to use LZ4 fast in order to support compression in lustre and
(mostly, based on that) investigate data reduction techniques in behalf
of storage systems.
Also, it will be useful for other users of LZ4 compression, as with LZ4
fast it is possible to enable applications to use fast and/or high
compression depending on the usecase. For instance, ZRAM is offering a
LZ4 backend and could benefit from an updated LZ4 in the kernel.
LZ4 homepage: http://www.lz4.org/
LZ4 source repository: https://github.com/lz4/lz4 Source version: 1.7.3
Benchmark (taken from [1], Core i5-4300U @1.9GHz):
----------------|--------------|----------------|----------
Compressor | Compression | Decompression | Ratio
----------------|--------------|----------------|----------
memcpy | 4200 MB/s | 4200 MB/s | 1.000
LZ4 fast 50 | 1080 MB/s | 2650 MB/s | 1.375
LZ4 fast 17 | 680 MB/s | 2220 MB/s | 1.607
LZ4 fast 5 | 475 MB/s | 1920 MB/s | 1.886
LZ4 default | 385 MB/s | 1850 MB/s | 2.101
[1] http://fastcompression.blogspot.de/2015/04/sampling-or-faster-lz4.html
[PATCH 1/5] lib: Update LZ4 compressor module
[PATCH 2/5] lib/decompress_unlz4: Change module to work with new LZ4 module version
[PATCH 3/5] crypto: Change LZ4 modules to work with new LZ4 module version
[PATCH 4/5] fs/pstore: fs/squashfs: Change usage of LZ4 to work with new LZ4 version
[PATCH 5/5] lib/lz4: Remove back-compat wrappers
This patch (of 5):
Update the LZ4 kernel module to LZ4 v1.7.3 by Yann Collet. The kernel
module is inspired by the previous work by Chanho Min. The updated LZ4
module will not break existing code since the patchset contains
appropriate changes.
API changes:
New method LZ4_compress_fast which differs from the variant available in
kernel by the new acceleration parameter, allowing to trade compression
ratio for more compression speed and vice versa.
LZ4_decompress_fast is the respective decompression method, featuring a
very fast decoder (multiple GB/s per core), able to reach RAM speed in
multi-core systems. The decompressor allows to decompress data
compressed with LZ4 fast as well as the LZ4 HC (high compression)
algorithm.
Also the useful functions LZ4_decompress_safe_partial and
LZ4_compress_destsize were added. The latter reverses the logic by
trying to compress as much data as possible from source to dest while
the former aims to decompress partial blocks of data.
A bunch of streaming functions were also added which allow
compressig/decompressing data in multiple steps (so called "streaming
mode").
The methods lz4_compress and lz4_decompress_unknownoutputsize are now
known as LZ4_compress_default respectivley LZ4_decompress_safe. The old
methods will be removed since there's no callers left in the code.
[arnd@arndb.de: fix KERNEL_LZ4 support]
Link: http://lkml.kernel.org/r/20170208211946.2839649-1-arnd@arndb.de
[akpm@linux-foundation.org: simplify]
[akpm@linux-foundation.org: fix the simplification]
[4sschmid@informatik.uni-hamburg.de: fix performance regressions]
Link: http://lkml.kernel.org/r/1486898178-17125-2-git-send-email-4sschmid@informatik.uni-hamburg.de
[4sschmid@informatik.uni-hamburg.de: v8]
Link: http://lkml.kernel.org/r/1487182598-15351-2-git-send-email-4sschmid@informatik.uni-hamburg.de
Link: http://lkml.kernel.org/r/1486321748-19085-2-git-send-email-4sschmid@informatik.uni-hamburg.de
Signed-off-by: Sven Schmidt <4sschmid@informatik.uni-hamburg.de>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Bongkyu Kim <bongkyu.kim@lge.com>
Cc: Rui Salvaterra <rsalvaterra@gmail.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: David S. Miller <davem@davemloft.net>
Cc: Anton Vorontsov <anton@enomsg.org>
Cc: Colin Cross <ccross@android.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Tony Luck <tony.luck@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Rui Salvaterra [Sat, 9 Apr 2016 21:05:35 +0000 (22:05 +0100)]
lib: lz4: cleanup unaligned access efficiency detection
These identifiers are bogus. The interested architectures should define
HAVE_EFFICIENT_UNALIGNED_ACCESS whenever relevant to do so. If this
isn't true for some arch, it should be fixed in the arch definition.
Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>
Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bongkyu Kim [Wed, 20 Jan 2016 23:01:08 +0000 (15:01 -0800)]
lz4: fix wrong compress buffer size for 64-bits
The current lz4 compress buffer is 16kb on 32-bits, 32kb on 64-bits
system. But, lz4 needs only 16kb on both. On 64-bits, this causes
wasted cpu cycles for additional memset during every compression.
In case of lz4hc, the current buffer size is (256kb + 8) on 32-bits,
(512kb + 16) on 64-bits. But, lz4hc needs only (256kb + 2 * pointer) on
both.
This patch fixes these wrong compress buffer sizes for 64-bits.
Signed-off-by: Bongkyu Kim <bongkyu.kim@lge.com>
Cc: Chanho Min <chanho.min@lge.com>
Cc: Yann Collet <yann.collet.73@gmail.com>
Cc: Kyungsik Lee <kyungsik.lee@lge.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
wloot [Sun, 27 Jan 2019 04:56:57 +0000 (12:56 +0800)]
random: fix a unused function warning
Park Ju Hyung [Fri, 5 May 2017 16:19:28 +0000 (01:19 +0900)]
random: always use /dev/urandom
/dev/random on Android cannot even properly generate a UUID;
it's practically unusable.
There are no programs/applications on Android that should use /dev/random.
Signed-off-by: Park Ju Hyung <qkrwngud825@gmail.com>
Signed-off-by: Alex Naidis <alex.naidis@linux.com>
Jason A. Donenfeld [Sun, 22 Jan 2017 15:34:08 +0000 (16:34 +0100)]
random: convert get_random_int/long into get_random_u32/u64
Many times, when a user wants a random number, he wants a random number
of a guaranteed size. So, thinking of get_random_int and get_random_long
in terms of get_random_u32 and get_random_u64 makes it much easier to
achieve this. It also makes the code simpler.
On 32-bit platforms, get_random_int and get_random_long are both aliased
to get_random_u32. On 64-bit platforms, int->u32 and long->u64.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Alex Naidis <alex.naidis@linux.com>
Jason A. Donenfeld [Fri, 6 Jan 2017 18:32:01 +0000 (19:32 +0100)]
random: use chacha20 for get_random_int/long
Now that our crng uses chacha20, we can rely on its speedy
characteristics for replacing MD5, while simultaneously achieving a
higher security guarantee. Before the idea was to use these functions if
you wanted random integers that aren't stupidly insecure but aren't
necessarily secure either, a vague gray zone, that hopefully was "good
enough" for its users. With chacha20, we can strengthen this claim,
since either we're using an rdrand-like instruction, or we're using the
same crng as /dev/urandom. And it's faster than what was before.
We could have chosen to replace this with a SipHash-derived function,
which might be slightly faster, but at the cost of having yet another
RNG construction in the kernel. By moving to chacha20, we have a single
RNG to analyze and verify, and we also already get good performance
improvements on all platforms.
Implementation-wise, rather than use a generic buffer for both
get_random_int/long and memcpy based on the size needs, we use a
specific buffer for 32-bit reads and for 64-bit reads. This way, we're
guaranteed to always have aligned accesses on all platforms. While
slightly more verbose in C, the assembly this generates is a lot
simpler than otherwise.
Finally, on 32-bit platforms where longs and ints are the same size,
we simply alias get_random_int to get_random_long.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Suggested-by: Theodore Ts'o <tytso@mit.edu>
Cc: Theodore Ts'o <tytso@mit.edu>
Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Alex Naidis <alex.naidis@linux.com>
Stephan Müller [Tue, 27 Dec 2016 22:41:22 +0000 (23:41 +0100)]
random: fix comment for unused random_min_urandom_seed
The variable random_min_urandom_seed is not needed any more as it
defined the reseeding behavior of the nonblocking pool. Though it is not
needed any more, it is left in the code for user space interface
compatibility.
Signed-off-by: Stephan Mueller <smueller@chronox.de>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Alex Naidis <alex.naidis@linux.com>
Stephan Müller [Tue, 27 Dec 2016 22:40:59 +0000 (23:40 +0100)]
random: remove variable limit
The variable limit was used to identify the nonblocking pool's unlimited
random number generation. As the nonblocking pool is a thing of the
past, remove the limit variable and any conditions around it (i.e.
preserve the branches for limit == 1).
Signed-off-by: Stephan Mueller <smueller@chronox.de>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Alex Naidis <alex.naidis@linux.com>
Stephan Müller [Tue, 27 Dec 2016 22:39:31 +0000 (23:39 +0100)]
random: remove stale urandom_init_wait
The urandom_init_wait wait queue is a left over from the pre-ChaCha20
times and can therefore be savely removed.
Signed-off-by: Stephan Mueller <smueller@chronox.de>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Alex Naidis <alex.naidis@linux.com>
Park Ju Hyung [Wed, 3 Aug 2016 03:22:36 +0000 (12:22 +0900)]
random: fully switch to Chacha20
Signed-off-by: Park Ju Hyung <qkrwngud825@gmail.com>
Signed-off-by: Alex Naidis <alex.naidis@linux.com>
Theodore Ts'o [Sun, 12 Jun 2016 22:13:36 +0000 (18:13 -0400)]
crypto: prepare to replace non-blocking pool with a Chacha20-based CRNG
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Alex Naidis <alex.naidis@linux.com>
Jason A. Donenfeld [Sun, 6 Dec 2015 01:51:38 +0000 (02:51 +0100)]
crypto: chacha20poly1305 - Skip encryption/decryption for 0-len
If the length of the plaintext is zero, there's no need to waste cycles
on encryption and decryption. Using the chacha20poly1305 construction
for zero-length plaintexts is a common way of using a shared encryption
key for AAD authentication.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Alex Naidis <alex.naidis@linux.com>
Sultan Alsawaf [Sun, 13 May 2018 20:01:46 +0000 (13:01 -0700)]
power: reset: msm: Always perform a regular reboot upon panic
Perform a normal reboot upon panic so the user won't find their phone
rebooted into download mode or something.
Also perform a regular reboot when the restart command is unknown.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
sbwml [Wed, 4 Dec 2019 08:39:45 +0000 (16:39 +0800)]
Merge Linux 4.4.206-rc1 into 10
Greg Kroah-Hartman [Tue, 3 Dec 2019 21:27:23 +0000 (22:27 +0100)]
Linux 4.4.206-rc1
Hans de Goede [Fri, 22 Nov 2019 18:56:40 +0000 (19:56 +0100)]
platform/x86: hp-wmi: Fix ACPI errors caused by too small buffer
commit
16245db1489cd9aa579506f64afeeeb13d825a93 upstream.
The HP WMI calls may take up to 128 bytes of data as input, and
the AML methods implementing the WMI calls, declare a couple of fields for
accessing input in different sizes, specifycally the HWMC method contains:
CreateField (Arg1, 0x80, 0x0400, D128)
Even though we do not use any of the WMI command-types which need a buffer
of this size, the APCI interpreter still tries to create it as it is
declared in generoc code at the top of the HWMC method which runs before
the code looks at which command-type is requested.
This results in many of these errors on many different HP laptop models:
[ 14.459261] ACPI Error: Field [D128] at 1152 exceeds Buffer [NULL] size 160 (bits) (
20170303/dsopcode-236)
[ 14.459268] ACPI Error: Method parse/execution failed [\HWMC] (Node
ffff8edcc61507f8), AE_AML_BUFFER_LIMIT (
20170303/psparse-543)
[ 14.459279] ACPI Error: Method parse/execution failed [\_SB.WMID.WMAA] (Node
ffff8edcc61523c0), AE_AML_BUFFER_LIMIT (
20170303/psparse-543)
This commit increases the size of the data element of the bios_args struct
to 128 bytes fixing these errors.
Cc: stable@vger.kernel.org
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=197007
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=201981
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1520703
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lionel Debieve [Mon, 1 Apr 2019 10:30:45 +0000 (12:30 +0200)]
hwrng: stm32 - fix unbalanced pm_runtime_enable
commit
af0d4442dd6813de6e77309063beb064fa8e89ae upstream.
No remove function implemented yet in the driver.
Without remove function, the pm_runtime implementation
complains when removing and probing again the driver.
Signed-off-by: Lionel Debieve <lionel.debieve@st.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Candle Sun [Tue, 22 Oct 2019 14:21:39 +0000 (22:21 +0800)]
HID: core: check whether Usage Page item is after Usage ID items
commit
1cb0d2aee26335d0bccf29100c7bed00ebece851 upstream.
Upstream commit
58e75155009c ("HID: core: move Usage Page concatenation
to Main item") adds support for Usage Page item after Usage ID items
(such as keyboards manufactured by Primax).
Usage Page concatenation in Main item works well for following report
descriptor patterns:
USAGE_PAGE (Keyboard) 05 07
USAGE_MINIMUM (Keyboard LeftControl) 19 E0
USAGE_MAXIMUM (Keyboard Right GUI) 29 E7
LOGICAL_MINIMUM (0) 15 00
LOGICAL_MAXIMUM (1) 25 01
REPORT_SIZE (1) 75 01
REPORT_COUNT (8) 95 08
INPUT (Data,Var,Abs) 81 02
-------------
USAGE_MINIMUM (Keyboard LeftControl) 19 E0
USAGE_MAXIMUM (Keyboard Right GUI) 29 E7
LOGICAL_MINIMUM (0) 15 00
LOGICAL_MAXIMUM (1) 25 01
REPORT_SIZE (1) 75 01
REPORT_COUNT (8) 95 08
USAGE_PAGE (Keyboard) 05 07
INPUT (Data,Var,Abs) 81 02
But it makes the parser act wrong for the following report
descriptor pattern(such as some Gamepads):
USAGE_PAGE (Button) 05 09
USAGE (Button 1) 09 01
USAGE (Button 2) 09 02
USAGE (Button 4) 09 04
USAGE (Button 5) 09 05
USAGE (Button 7) 09 07
USAGE (Button 8) 09 08
USAGE (Button 14) 09 0E
USAGE (Button 15) 09 0F
USAGE (Button 13) 09 0D
USAGE_PAGE (Consumer Devices) 05 0C
USAGE (Back) 0a 24 02
USAGE (HomePage) 0a 23 02
LOGICAL_MINIMUM (0) 15 00
LOGICAL_MAXIMUM (1) 25 01
REPORT_SIZE (1) 75 01
REPORT_COUNT (11) 95 0B
INPUT (Data,Var,Abs) 81 02
With Usage Page concatenation in Main item, parser recognizes all the
11 Usages as consumer keys, it is not the HID device's real intention.
This patch checks whether Usage Page is really defined after Usage ID
items by comparing usage page using status.
Usage Page concatenation on currently defined Usage Page will always
do in local parsing when Usage ID items encountered.
When Main item is parsing, concatenation will do again with last
defined Usage Page if this page has not been used in the previous
usages concatenation.
Signed-off-by: Candle Sun <candle.sun@unisoc.com>
Signed-off-by: Nianfu Bai <nianfu.bai@unisoc.com>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Cc: Siarhei Vishniakou <svv@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dust Li [Thu, 28 Nov 2019 06:29:09 +0000 (14:29 +0800)]
net: sched: fix `tc -s class show` no bstats on class with nolock subqueues
[ Upstream commit
14e54ab9143fa60794d13ea0a66c792a2046a8f3 ]
When a classful qdisc's child qdisc has set the flag
TCQ_F_CPUSTATS (pfifo_fast for example), the child qdisc's
cpu_bstats should be passed to gnet_stats_copy_basic(),
but many classful qdisc didn't do that. As a result,
`tc -s class show dev DEV` always return 0 for bytes and
packets in this case.
Pass the child qdisc's cpu_bstats to gnet_stats_copy_basic()
to fix this issue.
The qstats also has this problem, but it has been fixed
in
5dd431b6b9 ("net: sched: introduce and use qstats read...")
and bstats still remains buggy.
Fixes:
22e0f8b9322c ("net: sched: make bstats per cpu and estimator RCU safe")
Signed-off-by: Dust Li <dust.li@linux.alibaba.com>
Signed-off-by: Tony Lu <tonylu@linux.alibaba.com>
Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
John Rutherford [Tue, 26 Nov 2019 02:52:55 +0000 (13:52 +1100)]
tipc: fix link name length check
[ Upstream commit
fd567ac20cb0377ff466d3337e6e9ac5d0cb15e4 ]
In commit
4f07b80c9733 ("tipc: check msg->req data len in
tipc_nl_compat_bearer_disable") the same patch code was copied into
routines: tipc_nl_compat_bearer_disable(),
tipc_nl_compat_link_stat_dump() and tipc_nl_compat_link_reset_stats().
The two link routine occurrences should have been modified to check
the maximum link name length and not bearer name length.
Fixes:
4f07b80c9733 ("tipc: check msg->reg data len in tipc_nl_compat_bearer_disable")
Signed-off-by: John Rutherford <john.rutherford@dektech.com.au>
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Paolo Abeni [Sun, 1 Dec 2019 17:41:25 +0000 (18:41 +0100)]
openvswitch: remove another BUG_ON()
[ Upstream commit
8a574f86652a4540a2433946ba826ccb87f398cc ]
If we can't build the flow del notification, we can simply delete
the flow, no need to crash the kernel. Still keep a WARN_ON to
preserve debuggability.
Note: the BUG_ON() predates the Fixes tag, but this change
can be applied only after the mentioned commit.
v1 -> v2:
- do not leak an skb on error
Fixes:
aed067783e50 ("openvswitch: Minimize ovs_flow_cmd_del critical section.")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Paolo Abeni [Sun, 1 Dec 2019 17:41:24 +0000 (18:41 +0100)]
openvswitch: drop unneeded BUG_ON() in ovs_flow_cmd_build_info()
[ Upstream commit
8ffeb03fbba3b599690b361467bfd2373e8c450f ]
All the callers of ovs_flow_cmd_build_info() already deal with
error return code correctly, so we can handle the error condition
in a more gracefull way. Still dump a warning to preserve
debuggability.
v1 -> v2:
- clarify the commit message
- clean the skb and report the error (DaveM)
Fixes:
ccb1352e76cf ("net: Add Open vSwitch kernel components.")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jouni Hogander [Mon, 25 Nov 2019 12:23:43 +0000 (14:23 +0200)]
slip: Fix use-after-free Read in slip_open
[ Upstream commit
e58c1912418980f57ba2060017583067f5f71e52 ]
Slip_open doesn't clean-up device which registration failed from the
slip_devs device list. On next open after failure this list is iterated
and freed device is accessed. Fix this by calling sl_free_netdev in error
path.
Here is the trace from the Syzbot:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x197/0x210 lib/dump_stack.c:118
print_address_description.constprop.0.cold+0xd4/0x30b mm/kasan/report.c:374
__kasan_report.cold+0x1b/0x41 mm/kasan/report.c:506
kasan_report+0x12/0x20 mm/kasan/common.c:634
__asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132
sl_sync drivers/net/slip/slip.c:725 [inline]
slip_open+0xecd/0x11b7 drivers/net/slip/slip.c:801
tty_ldisc_open.isra.0+0xa3/0x110 drivers/tty/tty_ldisc.c:469
tty_set_ldisc+0x30e/0x6b0 drivers/tty/tty_ldisc.c:596
tiocsetd drivers/tty/tty_io.c:2334 [inline]
tty_ioctl+0xe8d/0x14f0 drivers/tty/tty_io.c:2594
vfs_ioctl fs/ioctl.c:46 [inline]
file_ioctl fs/ioctl.c:509 [inline]
do_vfs_ioctl+0xdb6/0x13e0 fs/ioctl.c:696
ksys_ioctl+0xab/0xd0 fs/ioctl.c:713
__do_sys_ioctl fs/ioctl.c:720 [inline]
__se_sys_ioctl fs/ioctl.c:718 [inline]
__x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718
do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Fixes:
3b5a39979daf ("slip: Fix memory leak in slip_open error path")
Reported-by: syzbot+4d5170758f3762109542@syzkaller.appspotmail.com
Cc: David Miller <davem@davemloft.net>
Cc: Oliver Hartkopp <socketcan@hartkopp.net>
Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Signed-off-by: Jouni Hogander <jouni.hogander@unikie.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>