linux.git/mm/Kconfig, branch v3.18.103

mm/balloon_compaction: add vmstat counters and kpageflags bit

2014-10-10T02:26:01+00:00

Always mark pages with PageBalloon even if balloon compaction is disabled
and expose this mark in /proc/kpageflags as KPF_BALLOON.

Also this patch adds three counters into /proc/vmstat: "balloon_inflate",
"balloon_deflate" and "balloon_migrate".  They accumulate balloon
activity.  Current size of balloon is (balloon_inflate - balloon_deflate)
pages.

All generic balloon code now gathered under option CONFIG_MEMORY_BALLOON.
It should be selected by ballooning driver which wants use this feature.
Currently virtio-balloon is the only user.

Signed-off-by: Konstantin Khlebnikov 
Cc: Rafael Aquini 
Cc: Andrey Ryabinin 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm: introduce a general RCU get_user_pages_fast()

2014-10-10T02:26:00+00:00

This series implements general forms of get_user_pages_fast and
__get_user_pages_fast in core code and activates them for arm and arm64.

These are required for Transparent HugePages to function correctly, as a
futex on a THP tail will otherwise result in an infinite loop (due to the
core implementation of __get_user_pages_fast always returning 0).

Unfortunately, a futex on THP tail can be quite common for certain
workloads; thus THP is unreliable without a __get_user_pages_fast
implementation.

This series may also be beneficial for direct-IO heavy workloads and
certain KVM workloads.

This patch (of 6):

get_user_pages_fast() attempts to pin user pages by walking the page
tables directly and avoids taking locks.  Thus the walker needs to be
protected from page table pages being freed from under it, and needs to
block any THP splits.

One way to achieve this is to have the walker disable interrupts, and rely
on IPIs from the TLB flushing code blocking before the page table pages
are freed.

On some platforms we have hardware broadcast of TLB invalidations, thus
the TLB flushing code doesn't necessarily need to broadcast IPIs; and
spuriously broadcasting IPIs can hurt system performance if done too
often.

This problem has been solved on PowerPC and Sparc by batching up page
table pages belonging to more than one mm_user, then scheduling an
rcu_sched callback to free the pages.  This RCU page table free logic has
been promoted to core code and is activated when one enables
HAVE_RCU_TABLE_FREE.  Unfortunately, these architectures implement their
own get_user_pages_fast routines.

The RCU page table free logic coupled with an IPI broadcast on THP split
(which is a rare event), allows one to protect a page table walker by
merely disabling the interrupts during the walk.

This patch provides a general RCU implementation of get_user_pages_fast
that can be used by architectures that perform hardware broadcast of TLB
invalidations.

It is based heavily on the PowerPC implementation by Nick Piggin.

[akpm@linux-foundation.org: various comment fixes]
Signed-off-by: Steve Capper 
Tested-by: Dann Frazier 
Reviewed-by: Catalin Marinas 
Acked-by: Hugh Dickins 
Cc: Russell King 
Cc: Mark Rutland 
Cc: Mel Gorman 
Cc: Will Deacon 
Cc: Christoffer Dall 
Cc: Andrea Arcangeli 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm/zpool: update zswap to use zpool

2014-08-07T01:01:23+00:00

Change zswap to use the zpool api instead of directly using zbud.  Add a
boot-time param to allow selecting which zpool implementation to use,
with zbud as the default.

Signed-off-by: Dan Streetman 
Tested-by: Seth Jennings 
Cc: Weijie Yang 
Cc: Minchan Kim 
Cc: Nitin Gupta 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm/zpool: implement common zpool api to zbud/zsmalloc

2014-08-07T01:01:23+00:00

Add zpool api.

zpool provides an interface for memory storage, typically of compressed
memory.  Users can select what backend to use; currently the only
implementations are zbud, a low density implementation with up to two
compressed pages per storage page, and zsmalloc, a higher density
implementation with multiple compressed pages per storage page.

Signed-off-by: Dan Streetman 
Tested-by: Seth Jennings 
Cc: Minchan Kim 
Cc: Nitin Gupta 
Cc: Weijie Yang 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

CMA: generalize CMA reserved area management functionality

2014-08-07T01:01:16+00:00

Currently, there are two users on CMA functionality, one is the DMA
subsystem and the other is the KVM on powerpc.  They have their own code
to manage CMA reserved area even if they looks really similar.  From my
guess, it is caused by some needs on bitmap management.  KVM side wants
to maintain bitmap not for 1 page, but for more size.  Eventually it use
bitmap where one bit represents 64 pages.

When I implement CMA related patches, I should change those two places
to apply my change and it seem to be painful to me.  I want to change
this situation and reduce future code management overhead through this
patch.

This change could also help developer who want to use CMA in their new
feature development, since they can use CMA easily without copying &
pasting this reserved area management code.

In previous patches, we have prepared some features to generalize CMA
reserved area management and now it's time to do it.  This patch moves
core functions to mm/cma.c and change DMA APIs to use these functions.

There is no functional change in DMA APIs.

Signed-off-by: Joonsoo Kim 
Acked-by: Michal Nazarewicz 
Acked-by: Zhang Yanfei 
Acked-by: Minchan Kim 
Reviewed-by: Aneesh Kumar K.V 
Cc: Alexander Graf 
Cc: Aneesh Kumar K.V 
Cc: Gleb Natapov 
Acked-by: Marek Szyprowski 
Tested-by: Marek Szyprowski 
Cc: Paolo Bonzini 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm/zsmalloc: make zsmalloc module-buildable

2014-06-04T23:54:14+00:00

Now, we can build zsmalloc as module because unmap_kernel_range was
exported.

Signed-off-by: Minchan Kim 
Cc: Nitin Gupta 
Cc: Sergey Senozhatsky 
Cc: Jerome Marchand 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm/process_vm_access: move config option into init/Kconfig

2014-06-04T23:54:12+00:00

CONFIG_CROSS_MEMORY_ATTACH adds couple syscalls: process_vm_readv and
process_vm_writev, it's a kind of IPC for copying data between processes.
Currently this option is placed inside "Processor type and features".

This patch moves it into "General setup" (where all other arch-independed
syscalls and ipc features are placed) and changes prompt string to less
cryptic.

Signed-off-by: Konstantin Khlebnikov 
Cc: Christopher Yeoh 
Cc: Davidlohr Bueso 
Cc: Hugh Dickins 
Cc: Al Viro 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

hugetlb: restrict hugepage_migration_support() to x86_64

2014-06-04T23:53:51+00:00

Currently hugepage migration is available for all archs which support
pmd-level hugepage, but testing is done only for x86_64 and there're
bugs for other archs.  So to avoid breaking such archs, this patch
limits the availability strictly to x86_64 until developers of other
archs get interested in enabling this feature.

Simply disabling hugepage migration on non-x86_64 archs is not enough to
fix the reported problem where sys_move_pages() hits the BUG_ON() in
follow_page(FOLL_GET), so let's fix this by checking if hugepage
migration is supported in vma_migratable().

Signed-off-by: Naoya Horiguchi 
Reported-by: Michael Ellerman 
Tested-by: Michael Ellerman 
Acked-by: Hugh Dickins 
Cc: Benjamin Herrenschmidt 
Cc: Tony Luck 
Cc: Russell King 
Cc: Martin Schwidefsky 
Cc: James Hogan 
Cc: Ralf Baechle 
Cc: David Miller 
Cc: 	[3.12+]
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm/memblock: add physical memory list

2014-05-20T06:58:39+00:00

Add the physmem list to the memblock structure. This list only exists
if HAVE_MEMBLOCK_PHYS_MAP is selected and contains the unmodified
list of physically available memory. It differs from the memblock
memory list as it always contains all memory ranges even if the
memory has been restricted, e.g. by use of the mem= kernel parameter.

Signed-off-by: Philipp Hachtmann 
Signed-off-by: Martin Schwidefsky

parisc,metag: Do not hardcode maximum userspace stack size

2014-05-14T23:01:41+00:00

This patch affects only architectures where the stack grows upwards
(currently parisc and metag only). On those do not hardcode the maximum
initial stack size to 1GB for 32-bit processes, but make it configurable
via a config option.

The main problem with the hardcoded stack size is, that we have two
memory regions which grow upwards: stack and heap. To keep most of the
memory available for heap in a flexmap memory layout, it makes no sense
to hard allocate up to 1GB of the memory for stack which can't be used
as heap then.

This patch makes the stack size for 32-bit processes configurable and
uses 80MB as default value which has been in use during the last few
years on parisc and which hasn't showed any problems yet.

Signed-off-by: Helge Deller 
Signed-off-by: James Hogan 
Cc: "James E.J. Bottomley" 
Cc: linux-parisc@vger.kernel.org
Cc: linux-metag@vger.kernel.org
Cc: John David Anglin