config SELECT_MEMORY_MODEL def_bool y depends on ARCH_SELECT_MEMORY_MODEL choice prompt "Memory model" depends on SELECT_MEMORY_MODEL default DISCONTIGMEM_MANUAL if ARCH_DISCONTIGMEM_DEFAULT default SPARSEMEM_MANUAL if ARCH_SPARSEMEM_DEFAULT default FLATMEM_MANUAL config FLATMEM_MANUAL bool "Flat Memory" depends on !(ARCH_DISCONTIGMEM_ENABLE || ARCH_SPARSEMEM_ENABLE) || ARCH_FLATMEM_ENABLE help This option allows you to change some of the ways that Linux manages its memory internally. Most users will only have one option here: FLATMEM. This is normal and a correct option. Some users of more advanced features like NUMA and memory hotplug may have different options here. DISCONTIGMEM is a more mature, better tested system, but is incompatible with memory hotplug and may suffer decreased performance over SPARSEMEM. If unsure between "Sparse Memory" and "Discontiguous Memory", choose "Discontiguous Memory". If unsure, choose this option (Flat Memory) over any other. config DISCONTIGMEM_MANUAL bool "Discontiguous Memory" depends on ARCH_DISCONTIGMEM_ENABLE help This option provides enhanced support for discontiguous memory systems, over FLATMEM. These systems have holes in their physical address spaces, and this option provides more efficient handling of these holes. However, the vast majority of hardware has quite flat address spaces, and can have degraded performance from the extra overhead that this option imposes. Many NUMA configurations will have this as the only option. If unsure, choose "Flat Memory" over this option. config SPARSEMEM_MANUAL bool "Sparse Memory" depends on ARCH_SPARSEMEM_ENABLE help This will be the only option for some systems, including memory hotplug systems. This is normal. For many other systems, this will be an alternative to "Discontiguous Memory". This option provides some potential performance benefits, along with decreased code complexity, but it is newer, and more experimental. If unsure, choose "Discontiguous Memory" or "Flat Memory" over this option. endchoice config DISCONTIGMEM def_bool y depends on (!SELECT_MEMORY_MODEL && ARCH_DISCONTIGMEM_ENABLE) || DISCONTIGMEM_MANUAL config SPARSEMEM def_bool y depends on (!SELECT_MEMORY_MODEL && ARCH_SPARSEMEM_ENABLE) || SPARSEMEM_MANUAL config FLATMEM def_bool y depends on (!DISCONTIGMEM && !SPARSEMEM) || FLATMEM_MANUAL config FLAT_NODE_MEM_MAP def_bool y depends on !SPARSEMEM # # Both the NUMA code and DISCONTIGMEM use arrays of pg_data_t's # to represent different areas of memory. This variable allows # those dependencies to exist individually. # config NEED_MULTIPLE_NODES def_bool y depends on DISCONTIGMEM || NUMA config HAVE_MEMORY_PRESENT def_bool y depends on ARCH_HAVE_MEMORY_PRESENT || SPARSEMEM # # SPARSEMEM_EXTREME (which is the default) does some bootmem # allocations when memory_present() is called. If this cannot # be done on your architecture, select this option. However, # statically allocating the mem_section[] array can potentially # consume vast quantities of .bss, so be careful. # # This option will also potentially produce smaller runtime code # with gcc 3.4 and later. # config SPARSEMEM_STATIC bool # # Architecture platforms which require a two level mem_section in SPARSEMEM # must select this option. This is usually for architecture platforms with # an extremely sparse physical address space. # config SPARSEMEM_EXTREME def_bool y depends on SPARSEMEM && !SPARSEMEM_STATIC config SPARSEMEM_VMEMMAP_ENABLE bool config SPARSEMEM_ALLOC_MEM_MAP_TOGETHER def_bool y depends on SPARSEMEM && X86_64 config SPARSEMEM_VMEMMAP bool "Sparse Memory virtual memmap" depends on SPARSEMEM && SPARSEMEM_VMEMMAP_ENABLE default y help SPARSEMEM_VMEMMAP uses a virtually mapped memmap to optimise pfn_to_page and page_to_pfn operations. This is the most efficient option when sufficient kernel resources are available. config HAVE_MEMBLOCK bool config HAVE_MEMBLOCK_NODE_MAP bool config HAVE_MEMBLOCK_PHYS_MAP bool config HAVE_GENERIC_RCU_GUP bool config ARCH_DISCARD_MEMBLOCK bool config NO_BOOTMEM bool config MEMORY_ISOLATION bool config MOVABLE_NODE bool "Enable to assign a node which has only movable memory" depends on HAVE_MEMBLOCK depends on NO_BOOTMEM depends on X86_64 depends on NUMA default n help Allow a node to have only movable memory. Pages used by the kernel, such as direct mapping pages cannot be migrated. So the corresponding memory device cannot be hotplugged. This option allows the following two things: - When the system is booting, node full of hotpluggable memory can be arranged to have only movable memory so that the whole node can be hot-removed. (need movable_node boot option specified). - After the system is up, the option allows users to online all the memory of a node as movable memory so that the whole node can be hot-removed. Users who don't use the memory hotplug feature are fin
#!/bin/bash
##############################################################################
# Copyright (c) 2015 Ericsson AB, Huawei Technologies Co.,Ltd and others.
#
# All rights reserved. This program and the accompanying materials
# are made available under the terms of the Apache License, Version 2.0
# which accompanies this distribution, and is available at
# http://www.apache.org/licenses/LICENSE-2.0
##############################################################################

# Clean the images and flavor before running yardstick test suites.

cleanup()
{
    echo
    echo "========== Cleanup =========="

    if [ $OS_INSECURE ] && [ "$(echo $OS_INSECURE | tr '[:upper:]' '[:lower:]')" = "true" ]; then
        SECURE="--insecure"
    else
        SECURE=""
    fi

    if ! openstack ${SECURE} image list; then
        return
    fi

    for image in $(openstack ${SECURE} image list | grep -e cirros-0.3.5 -e cirros-d161201 -e yardstick-image -e Ubuntu-16.04 \
        | awk '{print $2}'); do
        echo "Deleting image $image..."
        openstack ${SECURE} image delete $image || true
    done

    openstack ${SECURE} flavor delete yardstick-flavor &> /dev/null || true
    openstack ${SECURE} flavor delete storperf &> /dev/null || true
}

main()
{
    cleanup
}

main
elp Compressed memory storage API. This allows using either zbud or zsmalloc. config ZBUD tristate "Low density storage for compressed pages" default n help A 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. config ZSMALLOC tristate "Memory allocator for compressed pages" depends on MMU default n help zsmalloc is a slab-based memory allocator designed to store compressed RAM pages. zsmalloc uses virtual memory mapping in order to reduce fragmentation. However, this results in a non-standard allocator interface where a handle, not a pointer, is returned by an alloc(). This handle must be mapped in order to access the allocated space. config PGTABLE_MAPPING bool "Use page table mapping to access object in zsmalloc" depends on ZSMALLOC help By default, zsmalloc uses a copy-based object mapping method to access allocations that span two pages. However, if a particular architecture (ex, ARM) performs VM mapping faster than copying, then you should select this. This causes zsmalloc to use page table mapping rather than copying for object mapping. You can check speed with zsmalloc benchmark: https://github.com/spartacus06/zsmapbench config ZSMALLOC_STAT bool "Export zsmalloc statistics" depends on ZSMALLOC select DEBUG_FS help This option enables code in the zsmalloc to collect various statistics about whats happening in zsmalloc and exports that information to userspace via debugfs. If unsure, say N. config GENERIC_EARLY_IOREMAP bool config MAX_STACK_SIZE_MB int "Maximum user stack size for 32-bit processes (MB)" default 80 range 8 256 if METAG range 8 2048 depends on STACK_GROWSUP && (!64BIT || COMPAT) help This is the maximum stack size in Megabytes in the VM layout of 32-bit user processes when the stack grows upwards (currently only on parisc and metag arch). The stack will be located at the highest memory address minus the given value, unless the RLIMIT_STACK hard limit is changed to a smaller value in which case that is used. A sane initial value is 80 MB. # For architectures that support deferred memory initialisation config ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT bool config DEFERRED_STRUCT_PAGE_INIT bool "Defer initialisation of struct pages to kswapd" default n depends on ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT depends on MEMORY_HOTPLUG help Ordinarily all struct pages are initialised during early boot in a single thread. On very large machines this can take a considerable amount of time. If this option is set, large machines will bring up a subset of memmap at boot and then initialise the rest in parallel when kswapd starts. This has a potential performance impact on processes running early in the lifetime of the systemm until kswapd finishes the initialisation. config IDLE_PAGE_TRACKING bool "Enable idle page tracking" depends on SYSFS && MMU select PAGE_EXTENSION if !64BIT help This feature allows to estimate the amount of user pages that have not been touched during a given period of time. This information can be useful to tune memory cgroup limits and/or for job placement within a compute cluster. See Documentation/vm/idle_page_tracking.txt for more details. config ZONE_DEVICE bool "Device memory (pmem, etc...) hotplug support" if EXPERT default !ZONE_DMA depends on !ZONE_DMA depends on MEMORY_HOTPLUG depends on MEMORY_HOTREMOVE depends on X86_64 #arch_add_memory() comprehends device memory help Device memory hotplug support allows for establishing pmem, or other device driver discovered memory regions, in the memmap. This allows pfn_to_page() lookups of otherwise "device-physical" addresses which is needed for using a DAX mapping in an O_DIRECT operation, among other things. If FS_DAX is enabled, then say Y. config FRAME_VECTOR bool