linux-toradex.git/mm/Kconfig, branch v3.12.6

powerpc: Fix memory hotplug with sparse vmemmap

2013-10-03T07:21:38+00:00

Previous commit 46723bfa540... introduced a new config option
HAVE_BOOTMEM_INFO_NODE that ended up breaking memory hot-remove for ppc
when sparse vmemmap is not defined.

This patch defines HAVE_BOOTMEM_INFO_NODE for ppc and adds the call to
register_page_bootmem_info_node. Without this we get a BUG_ON for memory
hot remove in put_page_bootmem().

This also adds a stub for register_page_bootmem_memmap to allow ppc to build
with sparse vmemmap defined. Leaving this as a stub is fine since the same
vmemmap addresses are also handled in vmemmap_populate and as such are
properly mapped.

Signed-off-by: Nathan Fontenot 
Signed-off-by: Benjamin Herrenschmidt 
CC:  [v3.9+]

mm/Kconfig: add MMU dependency for MIGRATION.

2013-09-12T22:38:03+00:00

MIGRATION must depend on MMU, or allmodconfig for the nommu sh
architecture fails to build:

    CC      mm/migrate.o
  mm/migrate.c: In function 'remove_migration_pte':
  mm/migrate.c:134:3: error: implicit declaration of function 'pmd_trans_huge' [-Werror=implicit-function-declaration]
     if (pmd_trans_huge(*pmd))
     ^
  mm/migrate.c:149:2: error: implicit declaration of function 'is_swap_pte' [-Werror=implicit-function-declaration]
    if (!is_swap_pte(pte))
    ^
  ...

Also let CMA depend on MMU, or when NOMMU, if we select CMA, it will
select MIGRATION by force.

Signed-off-by: Chen Gang 
Reviewed-by: Michal Hocko 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Merge remote-tracking branch 'origin/next' into kvm-ppc-next

2013-08-28T22:41:59+00:00

Conflicts:
	mm/Kconfig

CMA DMA split and ZSWAP introduction were conflicting, fix up manually.

zswap: add to mm/

2013-07-11T01:11:34+00:00

zswap is a thin backend for frontswap that takes pages that are in the
process of being swapped out and attempts to compress them and store
them in a RAM-based memory pool.  This can result in a significant I/O
reduction on the swap device and, in the case where decompressing from
RAM is faster than reading from the swap device, can also improve
workload performance.

It also has support for evicting swap pages that are currently
compressed in zswap to the swap device on an LRU(ish) basis.  This
functionality makes zswap a true cache in that, once the cache is full,
the oldest pages can be moved out of zswap to the swap device so newer
pages can be compressed and stored in zswap.

This patch adds the zswap driver to mm/

Signed-off-by: Seth Jennings 
Acked-by: Rik van Riel 
Cc: Greg Kroah-Hartman 
Cc: Nitin Gupta 
Cc: Minchan Kim 
Cc: Konrad Rzeszutek Wilk 
Cc: Dan Magenheimer 
Cc: Robert Jennings 
Cc: Jenifer Hopper 
Cc: Mel Gorman 
Cc: Johannes Weiner 
Cc: Larry Woodman 
Cc: Benjamin Herrenschmidt 
Cc: Dave Hansen 
Cc: Joe Perches 
Cc: Joonsoo Kim 
Cc: Cody P Schafer 
Cc: Hugh Dickens 
Cc: Paul Mackerras 
Cc: Fengguang Wu 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

zbud: add to mm/

2013-07-11T01:11:34+00:00

zbud is an special purpose allocator for storing compressed pages.  It
is designed to store up to two compressed pages per physical page.
While this design limits storage density, it has simple and
deterministic reclaim properties that make it preferable to a higher
density approach when reclaim will be used.

zbud works by storing compressed pages, or "zpages", together in pairs
in a single memory page called a "zbud page".  The first buddy is "left
justifed" at the beginning of the zbud page, and the last buddy is
"right justified" at the end of the zbud page.  The benefit is that if
either buddy is freed, the freed buddy space, coalesced with whatever
slack space that existed between the buddies, results in the largest
possible free region within the zbud page.

zbud also provides an attractive lower bound on density.  The ratio of
zpages to zbud pages can not be less than 1.  This ensures that zbud can
never "do harm" by using more pages to store zpages than the
uncompressed zpages would have used on their own.

This implementation is a rewrite of the zbud allocator internally used
by zcache in the driver/staging tree.  The rewrite was necessary to
remove some of the zcache specific elements that were ingrained
throughout and provide a generic allocation interface that can later be
used by zsmalloc and others.

This patch adds zbud to mm/ for later use by zswap.

Signed-off-by: Seth Jennings 
Acked-by: Rik van Riel 
Cc: Greg Kroah-Hartman 
Cc: Nitin Gupta 
Cc: Minchan Kim 
Cc: Konrad Rzeszutek Wilk 
Cc: Dan Magenheimer 
Cc: Robert Jennings 
Cc: Jenifer Hopper 
Cc: Mel Gorman 
Cc: Johannes Weiner 
Cc: Larry Woodman 
Cc: Benjamin Herrenschmidt 
Cc: Dave Hansen 
Cc: Joe Perches 
Cc: Joonsoo Kim 
Cc: Cody P Schafer 
Cc: Hugh Dickens 
Cc: Paul Mackerras 
Cc: Bob Liu 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Merge remote-tracking branch 'cmadma/for-v3.12-cma-dma' into kvm-ppc-next

2013-07-08T14:16:56+00:00

Add prerequisite patch for CMA RMA allocation patches

mm: soft-dirty bits for user memory changes tracking

2013-07-03T23:07:26+00:00

The soft-dirty is a bit on a PTE which helps to track which pages a task
writes to.  In order to do this tracking one should

  1. Clear soft-dirty bits from PTEs ("echo 4 > /proc/PID/clear_refs)
  2. Wait some time.
  3. Read soft-dirty bits (55'th in /proc/PID/pagemap2 entries)

To do this tracking, the writable bit is cleared from PTEs when the
soft-dirty bit is.  Thus, after this, when the task tries to modify a
page at some virtual address the #PF occurs and the kernel sets the
soft-dirty bit on the respective PTE.

Note, that although all the task's address space is marked as r/o after
the soft-dirty bits clear, the #PF-s that occur after that are processed
fast.  This is so, since the pages are still mapped to physical memory,
and thus all the kernel does is finds this fact out and puts back
writable, dirty and soft-dirty bits on the PTE.

Another thing to note, is that when mremap moves PTEs they are marked
with soft-dirty as well, since from the user perspective mremap modifies
the virtual memory at mremap's new address.

Signed-off-by: Pavel Emelyanov 
Cc: Matt Mackall 
Cc: Xiao Guangrong 
Cc: Glauber Costa 
Cc: Marcelo Tosatti 
Cc: KOSAKI Motohiro 
Cc: Stephen Rothwell 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm/cma: Move dma contiguous changes into a seperate config

2013-07-02T08:08:22+00:00

We want to use CMA for allocating hash page table and real mode area for
PPC64. Hence move DMA contiguous related changes into a seperate config
so that ppc64 can enable CMA without requiring DMA contiguous.

Acked-by: Michal Nazarewicz 
Acked-by: Paul Mackerras 
Signed-off-by: Aneesh Kumar K.V 
[removed defconfig changes]
Signed-off-by: Marek Szyprowski

Finally eradicate CONFIG_HOTPLUG

2013-06-03T21:20:18+00:00

Ever since commit 45f035ab9b8f ("CONFIG_HOTPLUG should be always on"),
it has been basically impossible to build a kernel with CONFIG_HOTPLUG
turned off.  Remove all the remaining references to it.

Cc: Russell King 
Cc: Doug Thompson 
Cc: Bjorn Helgaas 
Cc: Steven Whitehouse 
Cc: Arnd Bergmann 
Cc: Pavel Machek 
Cc: "Rafael J. Wysocki" 
Cc: Andrew Morton 
Signed-off-by: Stephen Rothwell 
Acked-by: Mauro Carvalho Chehab 
Acked-by: Hans Verkuil 
Signed-off-by: Greg Kroah-Hartman

mmKconfig: add an option to disable bounce

2013-04-29T22:54:40+00:00

There are times when HIGHMEM is enabled, but we don't prefer
CONFIG_BOUNCE to be enabled.  CONFIG_BOUNCE can reduce the block device
throughput, and this is not ideal for machines where we don't gain much
by enabling it.  So provide an option to deselect CONFIG_BOUNCE.  The
observation was made while measuring eMMC throughput using iozone on an
ARM device with 1GB RAM.

Signed-off-by: Vinayak Menon 
Cc: David Rientjes 
Cc: Jens Axboe 
Cc: Randy Dunlap 
Cc: Russell King 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds