linux-toradex.git/include/linux/mm.h, branch v2.6.35.3

mm: add context argument to shrinker callback

2010-07-19T04:56:17+00:00

The current shrinker implementation requires the registered callback
to have global state to work from. This makes it difficult to shrink
caches that are not global (e.g. per-filesystem caches). Pass the shrinker
structure to the callback so that users can embed the shrinker structure
in the context the shrinker needs to operate on and get back to it in the
callback via container_of().

Signed-off-by: Dave Chinner 
Reviewed-by: Christoph Hellwig

mm: make lowmem_page_address() use PFN_PHYS() for improved portability

2010-05-25T15:07:02+00:00

This ensures that platforms with lowmem PAs above 32 bits work correctly
by avoiding truncating the PA during a left shift.

Signed-off-by: Chris Metcalf 
Cc: Barry Song <21cnbao@gmail.com>
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm: compaction: memory compaction core

2010-05-25T15:06:59+00:00

This patch is the core of a mechanism which compacts memory in a zone by
relocating movable pages towards the end of the zone.

A single compaction run involves a migration scanner and a free scanner.
Both scanners operate on pageblock-sized areas in the zone.  The migration
scanner starts at the bottom of the zone and searches for all movable
pages within each area, isolating them onto a private list called
migratelist.  The free scanner starts at the top of the zone and searches
for suitable areas and consumes the free pages within making them
available for the migration scanner.  The pages isolated for migration are
then migrated to the newly isolated free pages.

[aarcange@redhat.com: Fix unsafe optimisation]
[mel@csn.ul.ie: do not schedule work on other CPUs for compaction]
Signed-off-by: Mel Gorman 
Acked-by: Rik van Riel 
Reviewed-by: Minchan Kim 
Cc: KOSAKI Motohiro 
Cc: Christoph Lameter 
Cc: KAMEZAWA Hiroyuki 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm: migration: avoid race between shift_arg_pages() and rmap_walk() during migration by not migrating temporary stacks

2010-05-25T15:06:59+00:00

Page migration requires rmap to be able to find all ptes mapping a page
at all times, otherwise the migration entry can be instantiated, but it
is possible to leave one behind if the second rmap_walk fails to find
the page.  If this page is later faulted, migration_entry_to_page() will
call BUG because the page is locked indicating the page was migrated by
the migration PTE not cleaned up. For example

  kernel BUG at include/linux/swapops.h:105!
  invalid opcode: 0000 [#1] PREEMPT SMP
  ...
  Call Trace:
   [] handle_mm_fault+0x3f8/0x76a
   [] do_page_fault+0x44a/0x46e
   [] page_fault+0x25/0x30
   [] load_elf_binary+0x152a/0x192b
   [] search_binary_handler+0x173/0x313
   [] do_execve+0x219/0x30a
   [] sys_execve+0x43/0x5e
   [] stub_execve+0x6a/0xc0
  RIP  [] migration_entry_wait+0xc1/0x129

There is a race between shift_arg_pages and migration that triggers this
bug.  A temporary stack is setup during exec and later moved.  If
migration moves a page in the temporary stack and the VMA is then removed
before migration completes, the migration PTE may not be found leading to
a BUG when the stack is faulted.

This patch causes pages within the temporary stack during exec to be
skipped by migration.  It does this by marking the VMA covering the
temporary stack with an otherwise impossible combination of VMA flags.
These flags are cleared when the temporary stack is moved to its final
location.

[kamezawa.hiroyu@jp.fujitsu.com: idea for having migration skip temporary stacks]
Signed-off-by: Mel Gorman 
Reviewed-by: KAMEZAWA Hiroyuki 
Reviewed-by: Rik van Riel 
Acked-by: Linus Torvalds 
Cc: Minchan Kim 
Cc: Christoph Lameter 
Cc: Andrea Arcangeli 
Cc: Rik van Riel 
Cc: Peter Zijlstra 
Reviewed-by: KOSAKI Motohiro 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Merge branch 'linus' into perf/core

2010-04-08T11:37:18+00:00

Semantic conflict: arch/x86/kernel/cpu/perf_event_intel_ds.c

Merge reason: pick up latest fixes, fix the conflict

Signed-off-by: Ingo Molnar

pagemap: fix pfn calculation for hugepage

2010-04-07T15:38:04+00:00

When we look into pagemap using page-types with option -p, the value of
pfn for hugepages looks wrong (see below.) This is because pte was
evaluated only once for one vma although it should be updated for each
hugepage.  This patch fixes it.

  $ page-types -p 3277 -Nl -b huge
  voffset   offset  len     flags
  7f21e8a00 11e400  1       ___U___________H_G________________
  7f21e8a01 11e401  1ff     ________________TG________________
               ^^^
  7f21e8c00 11e400  1       ___U___________H_G________________
  7f21e8c01 11e401  1ff     ________________TG________________
               ^^^

One hugepage contains 1 head page and 511 tail pages in x86_64 and each
two lines represent each hugepage.  Voffset and offset mean virtual
address and physical address in the page unit, respectively.  The
different hugepages should not have the same offset value.

With this patch applied:

  $ page-types -p 3386 -Nl -b huge
  voffset   offset   len    flags
  7fec7a600 112c00   1      ___UD__________H_G________________
  7fec7a601 112c01   1ff    ________________TG________________
               ^^^
  7fec7a800 113200   1      ___UD__________H_G________________
  7fec7a801 113201   1ff    ________________TG________________
               ^^^
               OK

More info:

- This patch modifies walk_page_range()'s hugepage walker.  But the
  change only affects pagemap_read(), which is the only caller of hugepage
  callback.

- Without this patch, hugetlb_entry() callback is called per vma, that
  doesn't match the natural expectation from its name.

- With this patch, hugetlb_entry() is called per hugepte entry and the
  callback can become much simpler.

Signed-off-by: Naoya Horiguchi 
Signed-off-by: KAMEZAWA Hiroyuki 
Acked-by: Matt Mackall 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

x86, perf, bts, mm: Delete the never used BTS-ptrace code

2010-03-26T10:33:55+00:00

Support for the PMU's BTS features has been upstreamed in
v2.6.32, but we still have the old and disabled ptrace-BTS,
as Linus noticed it not so long ago.

It's buggy: TIF_DEBUGCTLMSR is trampling all over that MSR without
regard for other uses (perf) and doesn't provide the flexibility
needed for perf either.

Its users are ptrace-block-step and ptrace-bts, since ptrace-bts
was never used and ptrace-block-step can be implemented using a
much simpler approach.

So axe all 3000 lines of it. That includes the *locked_memory*()
APIs in mm/mlock.c as well.

Reported-by: Linus Torvalds 
Signed-off-by: Peter Zijlstra 
Cc: Roland McGrath 
Cc: Oleg Nesterov 
Cc: Markus Metzger 
Cc: Steven Rostedt 
Cc: Andrew Morton 
LKML-Reference: <20100325135413.938004390@chello.nl>
Signed-off-by: Ingo Molnar

mm: introduce dump_page() and print symbolic flag names

2010-03-12T23:52:28+00:00

- introduce dump_page() to print the page info for debugging some error
  condition.

- convert three mm users: bad_page(), print_bad_pte() and memory offline
  failure.

- print an extra field: the symbolic names of page->flags

Example dump_page() output:

[  157.521694] page:ffffea0000a7cba8 count:2 mapcount:1 mapping:ffff88001c901791 index:0x147
[  157.525570] page flags: 0x100000000100068(uptodate|lru|active|swapbacked)

Signed-off-by: Wu Fengguang 
Cc: Ingo Molnar 
Cc: Alex Chiang 
Cc: Rik van Riel 
Cc: Andi Kleen 
Cc: Mel Gorman 
Cc: Christoph Lameter 
Cc: KOSAKI Motohiro 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

nommu: fix build breakage

2010-03-12T23:52:28+00:00

Commit 34e55232e59f7b19050267a05ff1226e5cd122a5 ("mm: avoid false sharing
of mm_counter") added sync_mm_rss() for syncing loosely accounted rss
counters.  It's for CONFIG_MMU but sync_mm_rss is called even in NOMMU
enviroment (kerne/exit.c, fs/exec.c).  Above commit doesn't handle it
well.

This patch changes
  SPLIT_RSS_COUNTING depends on SPLIT_PTLOCKS && CONFIG_MMU

And for avoid unnecessary function calls, sync_mm_rss changed to be inlined
noop function in header file.

Reported-by: David Howells 
Signed-off-by: KAMEZAWA Hiroyuki 
Signed-off-by: Mike Frysinger 
Signed-off-by: Michal Simek 
Signed-off-by: David Howells 
Cc: Greg Ungerer 
Cc: Geert Uytterhoeven 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm: remove VM_LOCK_RMAP code

2010-03-06T19:26:26+00:00

When a VMA is in an inconsistent state during setup or teardown, the worst
that can happen is that the rmap code will not be able to find the page.

The mapping is in the process of being torn down (PTEs just got
invalidated by munmap), or set up (no PTEs have been instantiated yet).

It is also impossible for the rmap code to follow a pointer to an already
freed VMA, because the rmap code holds the anon_vma->lock, which the VMA
teardown code needs to take before the VMA is removed from the anon_vma
chain.

Hence, we should not need the VM_LOCK_RMAP locking at all.

Signed-off-by: Rik van Riel 
Cc: Nick Piggin 
Cc: KOSAKI Motohiro 
Cc: Larry Woodman 
Cc: Lee Schermerhorn 
Cc: Andrea Arcangeli 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds