* [PATCH 3.12 60/96] x86/mm: In the PTE swapout page reclaim case clear the accessed bit instead of flushing the TLB
2014-10-01 8:57 ` [PATCH 3.12 00/96] 3.12.30-stable review Jiri Slaby
@ 2014-10-01 8:57 ` Jiri Slaby
2014-10-01 16:23 ` [PATCH 3.12 00/96] 3.12.30-stable review Guenter Roeck
` (3 subsequent siblings)
4 siblings, 0 replies; 10+ messages in thread
From: Jiri Slaby @ 2014-10-01 8:57 UTC (permalink / raw)
To: stable
Cc: Shaohua Li, Shaohua Li, linux-mm, Peter Zijlstra, Ingo Molnar,
Mel Gorman, Jiri Slaby
From: Shaohua Li <shli@kernel.org>
3.12-stable review patch. If anyone has any objections, please let me know.
===============
commit b13b1d2d8692b437203de7a404c6b809d2cc4d99 upstream.
We use the accessed bit to age a page at page reclaim time,
and currently we also flush the TLB when doing so.
But in some workloads TLB flush overhead is very heavy. In my
simple multithreaded app with a lot of swap to several pcie
SSDs, removing the tlb flush gives about 20% ~ 30% swapout
speedup.
Fortunately just removing the TLB flush is a valid optimization:
on x86 CPUs, clearing the accessed bit without a TLB flush
doesn't cause data corruption.
It could cause incorrect page aging and the (mistaken) reclaim of
hot pages, but the chance of that should be relatively low.
So as a performance optimization don't flush the TLB when
clearing the accessed bit, it will eventually be flushed by
a context switch or a VM operation anyway. [ In the rare
event of it not getting flushed for a long time the delay
shouldn't really matter because there's no real memory
pressure for swapout to react to. ]
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Shaohua Li <shli@fusionio.com>
Acked-by: Rik van Riel <riel@redhat.com>
Acked-by: Mel Gorman <mgorman@suse.de>
Acked-by: Hugh Dickins <hughd@google.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: linux-mm@kvack.org
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/20140408075809.GA1764@kernel.org
[ Rewrote the changelog and the code comments. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Mel Gorman <mgorman@suse.de>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
arch/x86/mm/pgtable.c | 21 ++++++++++++++-------
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c
index dfa537a03be1..5da29d04de2f 100644
--- a/arch/x86/mm/pgtable.c
+++ b/arch/x86/mm/pgtable.c
@@ -386,13 +386,20 @@ int pmdp_test_and_clear_young(struct vm_area_struct *vma,
int ptep_clear_flush_young(struct vm_area_struct *vma,
unsigned long address, pte_t *ptep)
{
- int young;
-
- young = ptep_test_and_clear_young(vma, address, ptep);
- if (young)
- flush_tlb_page(vma, address);
-
- return young;
+ /*
+ * On x86 CPUs, clearing the accessed bit without a TLB flush
+ * doesn't cause data corruption. [ It could cause incorrect
+ * page aging and the (mistaken) reclaim of hot pages, but the
+ * chance of that should be relatively low. ]
+ *
+ * So as a performance optimization don't flush the TLB when
+ * clearing the accessed bit, it will eventually be flushed by
+ * a context switch or a VM operation anyway. [ In the rare
+ * event of it not getting flushed for a long time the delay
+ * shouldn't really matter because there's no real memory
+ * pressure for swapout to react to. ]
+ */
+ return ptep_test_and_clear_young(vma, address, ptep);
}
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
--
2.1.0
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related [flat|nested] 10+ messages in thread* Re: [PATCH 3.12 00/96] 3.12.30-stable review
2014-10-01 8:57 ` [PATCH 3.12 00/96] 3.12.30-stable review Jiri Slaby
2014-10-01 8:57 ` [PATCH 3.12 60/96] x86/mm: In the PTE swapout page reclaim case clear the accessed bit instead of flushing the TLB Jiri Slaby
@ 2014-10-01 16:23 ` Guenter Roeck
2014-10-10 8:17 ` Jiri Slaby
2014-10-01 16:24 ` Shuah Khan
` (2 subsequent siblings)
4 siblings, 1 reply; 10+ messages in thread
From: Guenter Roeck @ 2014-10-01 16:23 UTC (permalink / raw)
To: Jiri Slaby; +Cc: stable, satoru.takeuchi, shuah.kh, linux-kernel
On Wed, Oct 01, 2014 at 10:57:39AM +0200, Jiri Slaby wrote:
> This is the start of the stable review cycle for the 3.12.30 release.
> There are 96 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> This one is special. First, it is rounded (30). Second, most of the
> patches are performance improvements. They are coming from SUSE
> Enterprise Linux and all are backed by proper testing and performance
> measurements. All this patchset was prepared and sent by Mel Gorman
> with a support of other patchers from SUSE. Thanks to all of them.
>
> As this is special, I am gicing a whole week for responses. So
> responses should be made by Wed Oct 8 09:12:02 CEST 2014. Anything
> received after that time might be too late.
>
Build results:
total: 135 pass: 135 fail: 0
Qemu test results:
total: 23 pass: 23 fail: 0
Guenter
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH 3.12 00/96] 3.12.30-stable review
2014-10-01 16:23 ` [PATCH 3.12 00/96] 3.12.30-stable review Guenter Roeck
@ 2014-10-10 8:17 ` Jiri Slaby
0 siblings, 0 replies; 10+ messages in thread
From: Jiri Slaby @ 2014-10-10 8:17 UTC (permalink / raw)
To: Guenter Roeck; +Cc: stable, satoru.takeuchi, shuah.kh, linux-kernel
On 10/01/2014, 06:23 PM, Guenter Roeck wrote:> Build results:
> total: 135 pass: 135 fail: 0
> Qemu test results:
> total: 23 pass: 23 fail: 0
On 10/01/2014, 06:24 PM, Shuah Khan wrote:
> Compiled and booted on my test system. No dmesg regressions.
On 10/03/2014, 01:40 PM, Satoru Takeuchi wrote:
> This kernel passed my test.
Thank you all!
--
js
suse labs
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 3.12 00/96] 3.12.30-stable review
2014-10-01 8:57 ` [PATCH 3.12 00/96] 3.12.30-stable review Jiri Slaby
2014-10-01 8:57 ` [PATCH 3.12 60/96] x86/mm: In the PTE swapout page reclaim case clear the accessed bit instead of flushing the TLB Jiri Slaby
2014-10-01 16:23 ` [PATCH 3.12 00/96] 3.12.30-stable review Guenter Roeck
@ 2014-10-01 16:24 ` Shuah Khan
2014-10-03 11:40 ` Satoru Takeuchi
2014-10-10 7:32 ` William Dauchy
4 siblings, 0 replies; 10+ messages in thread
From: Shuah Khan @ 2014-10-01 16:24 UTC (permalink / raw)
To: Jiri Slaby, stable
Cc: linux, satoru.takeuchi, shuah.kh, linux-kernel, Shuah Khan
On 10/01/2014 02:57 AM, Jiri Slaby wrote:
> This is the start of the stable review cycle for the 3.12.30 release.
> There are 96 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> This one is special. First, it is rounded (30). Second, most of the
> patches are performance improvements. They are coming from SUSE
> Enterprise Linux and all are backed by proper testing and performance
> measurements. All this patchset was prepared and sent by Mel Gorman
> with a support of other patchers from SUSE. Thanks to all of them.
>
> As this is special, I am gicing a whole week for responses. So
> responses should be made by Wed Oct 8 09:12:02 CEST 2014. Anything
> received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> http://kernel.org/pub/linux/kernel/people/jirislaby/stable-review/patch-3.12.30-rc1.xz
> and the diffstat can be found below.
>
> thanks,
> js
>
Compiled and booted on my test system. No dmesg regressions.
-- Shuah
--
Shuah Khan
Sr. Linux Kernel Developer
Samsung Research America (Silicon Valley)
shuahkh@osg.samsung.com | (970) 217-8978
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 3.12 00/96] 3.12.30-stable review
2014-10-01 8:57 ` [PATCH 3.12 00/96] 3.12.30-stable review Jiri Slaby
` (2 preceding siblings ...)
2014-10-01 16:24 ` Shuah Khan
@ 2014-10-03 11:40 ` Satoru Takeuchi
2014-10-10 7:32 ` William Dauchy
4 siblings, 0 replies; 10+ messages in thread
From: Satoru Takeuchi @ 2014-10-03 11:40 UTC (permalink / raw)
To: Jiri Slaby; +Cc: stable, linux, satoru.takeuchi, shuah.kh, linux-kernel
At Wed, 1 Oct 2014 10:57:39 +0200,
Jiri Slaby wrote:
>
> This is the start of the stable review cycle for the 3.12.30 release.
> There are 96 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> This one is special. First, it is rounded (30). Second, most of the
> patches are performance improvements. They are coming from SUSE
> Enterprise Linux and all are backed by proper testing and performance
> measurements. All this patchset was prepared and sent by Mel Gorman
> with a support of other patchers from SUSE. Thanks to all of them.
>
> As this is special, I am gicing a whole week for responses. So
> responses should be made by Wed Oct 8 09:12:02 CEST 2014. Anything
> received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> http://kernel.org/pub/linux/kernel/people/jirislaby/stable-review/patch-3.12.30-rc1.xz
> and the diffstat can be found below.
>
> thanks,
> js
This kernel passed my test.
- Test Cases:
- Build this kernel.
- Boot this kernel.
- Build the latest mainline kernel with this kernel.
- Test Tool:
https://github.com/satoru-takeuchi/test-linux-stable
- Test Result (kernel .config, ktest config and test log):
http://satoru-takeuchi.org/test-linux-stable/results/<version>-<test datetime>.tar.xz
- Build Environment:
- OS: Debian Jessy x86_64
- CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4
- memory: 8GB
- Test Target Environment:
- Debian Jessy x86_64 (KVM guest on the Build Environment)
- # of vCPU: 2
- memory: 2GB
Thanks,
Satoru
>
> ===============
>
>
> Al Viro (1):
> callers of iov_copy_from_user_atomic() don't need pagecache_disable()
>
> Bob Liu (2):
> mm: thp: cleanup: mv alloc_hugepage to better place
> mm: thp: khugepaged: add policy for finding target node
>
> Christoph Lameter (1):
> vmscan: reclaim_clean_pages_from_list() must use mod_zone_page_state()
>
> Damien Ramonda (1):
> readahead: fix sequential read cache miss detection
>
> Dan Streetman (4):
> swap: change swap_info singly-linked list to list_head
> lib/plist: add helper functions
> lib/plist: add plist_requeue
> swap: change swap_list_head to plist, add swap_avail_head
>
> Dave Chinner (1):
> fs/superblock: unregister sb shrinker before ->kill_sb()
>
> David Rientjes (9):
> mm, compaction: avoid isolating pinned pages
> mm, compaction: determine isolation mode only once
> mm, compaction: ignore pageblock skip when manually invoking
> compaction
> mm, migration: add destination page freeing callback
> mm, compaction: return failed migration target pages back to freelist
> mm, compaction: add per-zone migration pfn cache for async compaction
> mm, compaction: embed migration mode in compact_control
> mm, compaction: terminate async compaction when rescheduling
> mm, thp: only collapse hugepages to nodes with affinity for
> zone_reclaim_mode
>
> Davidlohr Bueso (1):
> mm: per-thread vma caching
>
> Fabian Frederick (1):
> mm/readahead.c: inline ra_submit
>
> Han Pingtian (1):
> mm: prevent setting of a value less than 0 to min_free_kbytes
>
> Heesub Shin (1):
> mm/compaction: clean up unused code lines
>
> Hugh Dickins (4):
> mm: fix bad rss-counter if remap_file_pages raced migration
> mm: fix direct reclaim writeback regression
> shmem: fix init_page_accessed use to stop !PageLRU bug
> mm/memory.c: use entry = ACCESS_ONCE(*pte) in handle_pte_fault()
>
> Jens Axboe (1):
> mm/filemap.c: avoid always dirtying mapping->flags on O_DIRECT
>
> Jerome Marchand (2):
> mm: make copy_pte_range static again
> memcg, vmscan: Fix forced scan of anonymous pages
>
> Jianyu Zhan (1):
> mm/swap.c: clean up *lru_cache_add* functions
>
> Johannes Weiner (5):
> lib: radix-tree: add radix_tree_delete_item()
> mm: shmem: save one radix tree lookup when truncating swapped pages
> mm: filemap: move radix tree hole searching here
> mm + fs: prepare for non-page entries in page cache radix trees
> mm: madvise: fix MADV_WILLNEED on shmem swapouts
>
> Joonsoo Kim (7):
> slab: correct pfmemalloc check
> mm/compaction: disallow high-order page for migration target
> mm/compaction: do not call suitable_migration_target() on every page
> mm/compaction: change the timing to check to drop the spinlock
> mm/compaction: check pageblock suitability once per pageblock
> mm/compaction: clean-up code on success of ballon isolation
> vmalloc: use rcu list iterator to reduce vmap_area_lock contention
>
> KOSAKI Motohiro (2):
> mm: get rid of unnecessary overhead of trace_mm_page_alloc_extfrag()
> mm: __rmqueue_fallback() should respect pageblock type
>
> Linus Torvalds (1):
> mm: don't pointlessly use BUG_ON() for sanity check
>
> Mel Gorman (30):
> mm, x86: Account for TLB flushes only when debugging
> x86/mm: Clean up inconsistencies when flushing TLB ranges
> x86/mm: Eliminate redundant page table walk during TLB range flushing
> mm: compaction: trace compaction begin and end
> mm: optimize put_mems_allowed() usage
> mm: vmscan: use proportional scanning during direct reclaim and full
> scan at DEF_PRIORITY
> mm: page_alloc: do not update zlc unless the zlc is active
> mm: page_alloc: do not treat a zone that cannot be used for dirty
> pages as "full"
> include/linux/jump_label.h: expose the reference count
> mm: page_alloc: use jump labels to avoid checking number_of_cpusets
> mm: page_alloc: calculate classzone_idx once from the zonelist ref
> mm: page_alloc: only check the zone id check if pages are buddies
> mm: page_alloc: only check the alloc flags and gfp_mask for dirty once
> mm: page_alloc: take the ALLOC_NO_WATERMARK check out of the fast path
> mm: page_alloc: use unsigned int for order in more places
> mm: page_alloc: reduce number of times page_to_pfn is called
> mm: page_alloc: convert hot/cold parameter and immediate callers to
> bool
> mm: page_alloc: lookup pageblock migratetype with IRQs enabled during
> free
> mm: shmem: avoid atomic operation during shmem_getpage_gfp
> mm: do not use atomic operations when releasing pages
> mm: do not use unnecessary atomic operations when adding pages to the
> LRU
> fs: buffer: do not use unnecessary atomic operations when discarding
> buffers
> mm: non-atomically mark page accessed during page cache allocation
> where possible
> mm: avoid unnecessary atomic operations during end_page_writeback()
> mm: pagemap: avoid unnecessary overhead when tracepoints are
> deactivated
> mm: rearrange zone fields into read-only, page alloc, statistics and
> page reclaim lines
> mm: move zone->pages_scanned into a vmstat counter
> mm: vmscan: only update per-cpu thresholds for online CPU
> mm: page_alloc: abort fair zone allocation policy when remotes nodes
> are encountered
> mm: page_alloc: reduce cost of the fair zone allocation policy
>
> Michal Hocko (1):
> mm: exclude memoryless nodes from zone_reclaim
>
> Nishanth Aravamudan (1):
> hugetlb: ensure hugepage access is denied if hugepages are not
> supported
>
> Raghavendra K T (1):
> mm/readahead.c: fix readahead failure for memoryless NUMA nodes and
> limit readahead pages
>
> Sasha Levin (1):
> mm: remove read_cache_page_async()
>
> Shaohua Li (2):
> swap: add a simple detector for inappropriate swapin readahead
> x86/mm: In the PTE swapout page reclaim case clear the accessed bit
> instead of flushing the TLB
>
> Tim Chen (1):
> fs/superblock: avoid locking counting inodes and dentries before
> reclaiming them
>
> Vladimir Davydov (4):
> mm: vmscan: shrink all slab objects if tight on memory
> mm: vmscan: call NUMA-unaware shrinkers irrespective of nodemask
> mm: vmscan: respect NUMA policy mask when shrinking slab on direct
> reclaim
> mm: vmscan: shrink_slab: rename max_pass -> freeable
>
> Vlastimil Babka (8):
> mm: compaction: encapsulate defer reset logic
> mm: compaction: do not mark unmovable pageblocks as skipped in async
> compaction
> mm: compaction: reset scanner positions immediately when they meet
> mm/compaction: cleanup isolate_freepages()
> mm/compaction: do not count migratepages when unnecessary
> mm/compaction: avoid rescanning pageblocks in isolate_freepages
> mm, compaction: properly signal and act upon lock and need_sched()
> contention
> mm/page_alloc: prevent MIGRATE_RESERVE pages from being misplaced
>
> Yasuaki Ishimatsu (1):
> mm: get rid of unnecessary pageblock scanning in
> setup_zone_migrate_reserve
>
> arch/tile/mm/homecache.c | 2 +-
> arch/unicore32/include/asm/mmu_context.h | 4 +-
> arch/x86/include/asm/tlbflush.h | 6 +-
> arch/x86/kernel/cpu/mtrr/generic.c | 4 +-
> arch/x86/mm/pgtable.c | 21 +-
> arch/x86/mm/tlb.c | 52 +---
> fs/btrfs/compression.c | 2 +-
> fs/btrfs/extent_io.c | 15 +-
> fs/btrfs/file.c | 10 +-
> fs/buffer.c | 28 +-
> fs/cramfs/inode.c | 3 +-
> fs/exec.c | 5 +-
> fs/ext4/mballoc.c | 14 +-
> fs/f2fs/checkpoint.c | 1 -
> fs/f2fs/node.c | 2 -
> fs/fuse/dev.c | 2 +-
> fs/fuse/file.c | 4 -
> fs/gfs2/aops.c | 1 -
> fs/gfs2/meta_io.c | 4 +-
> fs/hugetlbfs/inode.c | 5 +
> fs/jffs2/fs.c | 2 +-
> fs/nfs/blocklayout/blocklayout.c | 2 +-
> fs/ntfs/attrib.c | 1 -
> fs/ntfs/file.c | 1 -
> fs/proc/task_mmu.c | 3 +-
> fs/super.c | 16 +-
> include/linux/compaction.h | 20 +-
> include/linux/cpuset.h | 56 ++--
> include/linux/gfp.h | 4 +-
> include/linux/huge_mm.h | 4 -
> include/linux/hugetlb.h | 10 +
> include/linux/jump_label.h | 20 +-
> include/linux/migrate.h | 11 +-
> include/linux/mm.h | 11 +-
> include/linux/mm_types.h | 4 +-
> include/linux/mmzone.h | 233 ++++++++-------
> include/linux/page-flags.h | 6 +-
> include/linux/pageblock-flags.h | 33 +--
> include/linux/pagemap.h | 131 +++++++--
> include/linux/pagevec.h | 5 +
> include/linux/plist.h | 45 +++
> include/linux/radix-tree.h | 5 +-
> include/linux/sched.h | 7 +
> include/linux/shmem_fs.h | 1 +
> include/linux/swap.h | 30 +-
> include/linux/swapfile.h | 2 +-
> include/linux/vm_event_item.h | 4 +-
> include/linux/vmacache.h | 38 +++
> include/linux/vmstat.h | 8 +
> include/trace/events/compaction.h | 67 ++++-
> include/trace/events/kmem.h | 10 +-
> include/trace/events/pagemap.h | 16 +-
> kernel/cpuset.c | 16 +-
> kernel/debug/debug_core.c | 14 +-
> kernel/fork.c | 7 +-
> lib/plist.c | 52 ++++
> lib/radix-tree.c | 106 ++-----
> mm/Makefile | 2 +-
> mm/compaction.c | 347 +++++++++++++----------
> mm/filemap.c | 470 +++++++++++++++++++++----------
> mm/fremap.c | 28 +-
> mm/frontswap.c | 13 +-
> mm/huge_memory.c | 93 ++++--
> mm/hugetlb.c | 17 +-
> mm/internal.h | 22 +-
> mm/madvise.c | 2 +-
> mm/memory-failure.c | 4 +-
> mm/memory.c | 4 +-
> mm/memory_hotplug.c | 2 +-
> mm/mempolicy.c | 16 +-
> mm/migrate.c | 56 ++--
> mm/mincore.c | 20 +-
> mm/mmap.c | 55 ++--
> mm/nommu.c | 24 +-
> mm/page_alloc.c | 423 ++++++++++++++++------------
> mm/readahead.c | 37 +--
> mm/shmem.c | 133 +++------
> mm/slab.c | 12 +-
> mm/slub.c | 16 +-
> mm/swap.c | 101 ++++++-
> mm/swap_state.c | 65 ++++-
> mm/swapfile.c | 224 ++++++++-------
> mm/truncate.c | 74 ++++-
> mm/vmacache.c | 114 ++++++++
> mm/vmalloc.c | 6 +-
> mm/vmscan.c | 144 ++++++----
> mm/vmstat.c | 13 +-
> 87 files changed, 2366 insertions(+), 1357 deletions(-)
> create mode 100644 include/linux/vmacache.h
> create mode 100644 mm/vmacache.c
>
> --
> 2.1.0
>
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH 3.12 00/96] 3.12.30-stable review
2014-10-01 8:57 ` [PATCH 3.12 00/96] 3.12.30-stable review Jiri Slaby
` (3 preceding siblings ...)
2014-10-03 11:40 ` Satoru Takeuchi
@ 2014-10-10 7:32 ` William Dauchy
2014-10-10 11:40 ` Greg Kroah-Hartman
2014-10-10 11:42 ` Holger Hoffstätte
4 siblings, 2 replies; 10+ messages in thread
From: William Dauchy @ 2014-10-10 7:32 UTC (permalink / raw)
To: stable
Cc: linux, satoru.takeuchi, shuah.kh, linux-kernel@vger.kernel.org,
Greg Kroah-Hartman, Jiri Slaby
Hi stable release team,
On Wed, Oct 1, 2014 at 10:57 AM, Jiri Slaby <jslaby@suse.cz> wrote:
> This one is special. First, it is rounded (30). Second, most of the
> patches are performance improvements. They are coming from SUSE
> Enterprise Linux and all are backed by proper testing and performance
> measurements. All this patchset was prepared and sent by Mel Gorman
> with a support of other patchers from SUSE. Thanks to all of them.
I'm just wondering if 3.10.x and 3.14.x are going to benefit from
these performance improvement patches as well.
Best regards,
--
William
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH 3.12 00/96] 3.12.30-stable review
2014-10-10 7:32 ` William Dauchy
@ 2014-10-10 11:40 ` Greg Kroah-Hartman
2014-10-10 11:45 ` William Dauchy
2014-10-10 11:42 ` Holger Hoffstätte
1 sibling, 1 reply; 10+ messages in thread
From: Greg Kroah-Hartman @ 2014-10-10 11:40 UTC (permalink / raw)
To: William Dauchy
Cc: stable, linux, satoru.takeuchi, shuah.kh,
linux-kernel@vger.kernel.org, Jiri Slaby
On Fri, Oct 10, 2014 at 09:32:45AM +0200, William Dauchy wrote:
> Hi stable release team,
>
> On Wed, Oct 1, 2014 at 10:57 AM, Jiri Slaby <jslaby@suse.cz> wrote:
> > This one is special. First, it is rounded (30). Second, most of the
> > patches are performance improvements. They are coming from SUSE
> > Enterprise Linux and all are backed by proper testing and performance
> > measurements. All this patchset was prepared and sent by Mel Gorman
> > with a support of other patchers from SUSE. Thanks to all of them.
>
> I'm just wondering if 3.10.x and 3.14.x are going to benefit from
> these performance improvement patches as well.
The last 3.14.x release had a bunch of these patches already in them,
with more to come in future releases, so yes, 3.14.x is going to benefit
from it, and you didn't even notice :)
But 3.10 will probably not, it's been just too long for that kernel
release, sorry, major mm changes like this isn't something I'm willing
to do at this point in time.
Hope this helps,
greg k-h
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 3.12 00/96] 3.12.30-stable review
2014-10-10 11:40 ` Greg Kroah-Hartman
@ 2014-10-10 11:45 ` William Dauchy
0 siblings, 0 replies; 10+ messages in thread
From: William Dauchy @ 2014-10-10 11:45 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: William Dauchy, stable, linux, satoru.takeuchi, shuah.kh,
linux-kernel@vger.kernel.org, Jiri Slaby
[-- Attachment #1: Type: text/plain, Size: 515 bytes --]
On Oct10 04:40, Greg Kroah-Hartman wrote:
> The last 3.14.x release had a bunch of these patches already in them,
> with more to come in future releases, so yes, 3.14.x is going to benefit
> from it, and you didn't even notice :)
oh true; did not catch the last one.
> But 3.10 will probably not, it's been just too long for that kernel
> release, sorry, major mm changes like this isn't something I'm willing
> to do at this point in time.
understood.
Thanks for your quick answer,
--
William
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 3.12 00/96] 3.12.30-stable review
2014-10-10 7:32 ` William Dauchy
2014-10-10 11:40 ` Greg Kroah-Hartman
@ 2014-10-10 11:42 ` Holger Hoffstätte
1 sibling, 0 replies; 10+ messages in thread
From: Holger Hoffstätte @ 2014-10-10 11:42 UTC (permalink / raw)
To: linux-kernel; +Cc: stable
On Fri, 10 Oct 2014 09:32:45 +0200, William Dauchy wrote:
> Hi stable release team,
>
> On Wed, Oct 1, 2014 at 10:57 AM, Jiri Slaby <jslaby@suse.cz> wrote:
>> This one is special. First, it is rounded (30). Second, most of the
>> patches are performance improvements. They are coming from SUSE
>> Enterprise Linux and all are backed by proper testing and performance
>> measurements. All this patchset was prepared and sent by Mel Gorman
>> with a support of other patchers from SUSE. Thanks to all of them.
>
> I'm just wondering if 3.10.x and 3.14.x are going to benefit from
> these performance improvement patches as well.
This set of patches was awesome but also pretty large and touched some
nontrivial parts, so it's not just a simple matter of merging them
wholesale.
I merged a handful of these patches to my own private 3.14.x tree where
they work wonderfully, and some have already appeared in the latest
stable-3.14.21. Greg also said that he has more in the queue. :)
The one I have so far punted on due to the filesystem dependencies is
2457aec63745e235bcafb7ef312b182d8682f0fc aka: "mm: non-atomically mark
page accessed during page cache allocation where possible" - that would
be really nice to have.
-h
^ permalink raw reply [flat|nested] 10+ messages in thread