Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 30 5月, 2009 2 次提交
  3. 18 5月, 2009 1 次提交
    • M
      [ARM] Double check memmap is actually valid with a memmap has unexpected holes V2 · eb33575c
      由 Mel Gorman 提交于 
      pfn_valid() is meant to be able to tell if a given PFN has valid memmap
associated with it or not. In FLATMEM, it is expected that holes always
have valid memmap as long as there is valid PFNs either side of the hole.
In SPARSEMEM, it is assumed that a valid section has a memmap for the
entire section.

However, ARM and maybe other embedded architectures in the future free
memmap backing holes to save memory on the assumption the memmap is never
used. The page_zone linkages are then broken even though pfn_valid()
returns true. A walker of the full memmap must then do this additional
check to ensure the memmap they are looking at is sane by making sure the
zone and PFN linkages are still valid. This is expensive, but walkers of
the full memmap are extremely rare.

This was caught before for FLATMEM and hacked around but it hits again for
SPARSEMEM because the page_zone linkages can look ok where the PFN linkages
are totally screwed. This looks like a hatchet job but the reality is that
any clean solution would end up consumning all the memory saved by punching
these unexpected holes in the memmap. For example, we tried marking the
memmap within the section invalid but the section size exceeds the size of
the hole in most cases so pfn_valid() starts returning false where valid
memmap exists. Shrinking the size of the section would increase memory
consumption offsetting the gains.

This patch identifies when an architecture is punching unexpected holes
in the memmap that the memory model cannot automatically detect and sets
ARCH_HAS_HOLES_MEMORYMODEL. At the moment, this is restricted to EP93xx
which is the model sub-architecture this has been reported on but may expand
later. When set, walkers of the full memmap must call memmap_valid_within()
for each PFN and passing in what it expects the page and zone to be for
that PFN. If it finds the linkages to be broken, it assumes the memmap is
invalid for that PFN.
Signed-off-by: NMel Gorman <mel@csn.ul.ie>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      eb33575c
  5. 05 5月, 2009 1 次提交
  7. 01 5月, 2009 4 次提交
  9. 27 4月, 2009 2 次提交
  11. 24 4月, 2009 2 次提交
  13. 26 3月, 2009 2 次提交
  15. 23 3月, 2009 5 次提交
  17. 16 3月, 2009 1 次提交
    • N
      [ARM] add CONFIG_HIGHMEM option · 053a96ca
      由 Nicolas Pitre 提交于 
      Here it is... HIGHMEM for the ARM architecture.  :-)

If you don't have enough ram for highmem pages to be allocated and still
want to test this, then the cmdline option "vmalloc=" can be used with
a value large enough to force the highmem threshold down.

Successfully tested on a Marvell DB-78x00-BP Development Board with
2 GB of RAM.
Signed-off-by: NNicolas Pitre <nico@marvell.com>
      053a96ca
  19. 22 2月, 2009 1 次提交
  21. 12 2月, 2009 1 次提交
  23. 07 1月, 2009 1 次提交
  25. 21 12月, 2008 2 次提交
  27. 16 12月, 2008 1 次提交
  29. 14 12月, 2008 1 次提交
  31. 12 12月, 2008 1 次提交
  33. 10 12月, 2008 2 次提交
  35. 04 12月, 2008 1 次提交
  37. 01 12月, 2008 2 次提交
  39. 27 11月, 2008 6 次提交
  41. 23 10月, 2008 1 次提交
    • S
      ftrace: disable dynamic ftrace for all archs that use daemon · 07c4cc1c
      由 Steven Rostedt 提交于 
      The ftrace daemon is complex and can cause nasty races if something goes
wrong. Since it affects all of the kernel, this patch disables dynamic
ftrace from any arch that depends on the daemon. Until the archs are
ported over to the new MCOUNT_RECORD method, I am disabling dynamic
ftrace from them.

Note: I am leaving in the arch/<arch>/kernel/ftrace.c code alone since
that can be used when the arch is ported to MCOUNT_RECORD. To port
the arch to MCOUNT_RECORD, the scripts/recordmcount.pl needs to be
updated. I will make that easier to do for 2.6.29. For 28, we will keep
the archs disabled.
Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      07c4cc1c