Shaohua Li [Tue, 29 Apr 2014 11:13:58 +0000 (19:13 +0800)]
raid5: add an option to avoid copy data from bio to stripe cache
The stripe cache has two goals:
1. cache data, so next time if data can be found in stripe cache, disk access
can be avoided.
2. stable data. data is copied from bio to stripe cache and calculated parity.
data written to disk is from stripe cache, so if upper layer changes bio data,
data written to disk isn't impacted.
In my environment, I can guarantee 2 will not happen. And BDI_CAP_STABLE_WRITES
can guarantee 2 too. For 1, it's not common too. block plug mechanism will
dispatch a bunch of sequentail small requests together. And since I'm using
SSD, I'm using small chunk size. It's rare case stripe cache is really useful.
So I'd like to avoid the copy from bio to stripe cache and it's very helpful
for performance. In my 1M randwrite tests, avoid the copy can increase the
performance more than 30%.
Of course, this shouldn't be enabled by default. It's reported enabling
BDI_CAP_STABLE_WRITES can harm some workloads before, so I added an option to
control it.
Neilb:
changed BUG_ON to WARN_ON
Removed some assignments from raid5_build_block which are now not needed.
Signed-off-by: Shaohua Li <shli@fusionio.com> Signed-off-by: NeilBrown <neilb@suse.de>
NeilBrown [Mon, 5 May 2014 23:36:08 +0000 (09:36 +1000)]
md: avoid possible spinning md thread at shutdown.
If an md array with externally managed metadata (e.g. DDF or IMSM)
is in use, then we should not set safemode==2 at shutdown because:
1/ this is ineffective: user-space need to be involved in any 'safemode' handling,
2/ The safemode management code doesn't cope with safemode==2 on external metadata
and md_check_recover enters an infinite loop.
Even at shutdown, an infinite-looping process can be problematic, so this
could cause shutdown to hang.
NeilBrown [Mon, 5 May 2014 03:34:37 +0000 (13:34 +1000)]
md/raid10: call wait_barrier() for each request submitted.
wait_barrier() includes a counter, so we must call it precisely once
(unless balanced by allow_barrier()) for each request submitted.
Since
commit 20d0189b1012a37d2533a87fb451f7852f2418d1
block: Introduce new bio_split()
in 3.14-rc1, we don't call it for the extra requests generated when
we need to split a bio.
When this happens the counter goes negative, any resync/recovery will
never start, and "mdadm --stop" will hang.
Reported-by: Chris Murphy <lists@colorremedies.com> Fixes: 20d0189b1012a37d2533a87fb451f7852f2418d1 Cc: stable@vger.kernel.org (3.14+) Cc: Kent Overstreet <kmo@daterainc.com> Signed-off-by: NeilBrown <neilb@suse.de>
* pm-cpufreq-next:
cpufreq: Kconfig: Fix spelling errors
cpufreq: Make linux-pm@vger.kernel.org official mailing list
cpufreq: exynos: Use dev_err/info function instead of pr_err/info
* acpica-next: (28 commits)
ACPICA: Update version to 20140325.
ACPICA: acpidump: Update man page.
ACPICA: acpidump: Remove old acpidump source.
ACPICA: acpidump: Update Makefile to build acpidump from ACPICA.
ACPICA: acpidump: Update new structures and add missing file.
ACPICA: acpidump: Add support to generate acpidump release.
ACPICA: Table Manager: Split tbinstal.c into two files.
ACPICA: Table Manager: Misc cleanup and renames, no functional change.
ACPICA: Tables: Add acpi_install_table() API for early table installation.
ACPICA: Tables: Avoid SSDT installation with acpi_gbl_disable_ssdt_table_load.
ACPICA: Tables: Cleanup ACPI_TABLE_ORIGIN_xxx flags.
ACPICA: Tables: Fix table checksums verification before installation.
ACPICA: Tables: Fix unbalanced table validations.
ACPICA: Tables: Clean up split INSTALLED/VALIDATED table state logics.
ACPICA: Tables: Fix multiple ACPI_FREE()s around acpi_tb_add_table().
ACPICA: Tables: Fix the issues in handling virtual addressed tables.
ACPICA: Remove indent divergences to reduce maintenance overhead.
ACPICA: Add a missing field for debug dump of mutex objects.
ACPICA: Linux-specific header: Add support for PPC64 compilation.
ACPICA: Clean up comment divergences in aclinux.h
...
ACPICA: Tables: Fix invalid pointer accesses in acpi_tb_parse_root_table().
Linux XSDT validation mechanism backport has introduced a regreession:
Commit: 671cc68dc61f029d44b43a681356078e02d8dab8
Subject: ACPICA: Back port and refine validation of the XSDT root table.
There is a pointer still accessed after unmapping.
This patch fixes this issue. Lv Zheng.
Fixes: 671cc68dc61f (ACPICA: Back port and refine validation of the XSDT root table.)
References: https://bugzilla.kernel.org/show_bug.cgi?id=73911
References: https://bugs.archlinux.org/task/39811 Signed-off-by: Lv Zheng <lv.zheng@intel.com> Reported-and-tested-by: Bruce Chiarelli <mano155@gmail.com> Reported-and-tested-by: Spyros Stathopoulos <spystath@gmail.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Cc: 3.14+ <stable@vger.kernel.org> # 3.14+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq-macros:
sh: clk: Use cpufreq_for_each_valid_entry macro for iteration
irda: sh_sir: Use cpufreq_for_each_valid_entry macro for iteration
thermal: cpu_cooling: Use cpufreq_for_each_valid_entry macro for iteration
mips: lemote 2f: Use cpufreq_for_each_entry macro for iteration
mfd: db8500-prcmu: Use cpufreq_for_each_entry macro for iteration
ARM: davinci: da850: Use cpufreq_for_each_entry macro for iteration
cpufreq: Use cpufreq_for_each_* macros for frequency table iteration
cpufreq: Introduce macros for cpufreq_frequency_table iteration
projects / karo-tx-linux.git / log