Since ion alloc can be called by userspace,eg gralloc.
When it is called frequently, the efficiency of kswapd is
to low. And the reclaimed memory is too lower. In this way,
the kswapd can use to much cpu resources.
With 3.5GB DMA Zone and 0.5 Normal Zone.
pgsteal_kswapd_dma 9364140
pgsteal_kswapd_normal 7071043
pgscan_kswapd_dma 10428250
pgscan_kswapd_normal 37840094
With this change the reclaim ratio has greatly improved
18.9% -> 72.5%
Signed-off-by: Chen Feng <puck.chen(a)hisilicon.com>
Signed-off-by: Lu bing <albert.lubing(a)hisilicon.com>
---
drivers/staging/android/ion/ion_system_heap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/android/ion/ion_system_heap.c b/drivers/staging/android/ion/ion_system_heap.c
index d4c3e55..b69dfc7 100644
--- a/drivers/staging/android/ion/ion_system_heap.c
+++ b/drivers/staging/android/ion/ion_system_heap.c
@@ -27,7 +27,7 @@
#include "ion_priv.h"
static gfp_t high_order_gfp_flags = (GFP_HIGHUSER | __GFP_ZERO | __GFP_NOWARN |
- __GFP_NORETRY) & ~__GFP_DIRECT_RECLAIM;
+ __GFP_NORETRY) & ~__GFP_RECLAIM;
static gfp_t low_order_gfp_flags = (GFP_HIGHUSER | __GFP_ZERO | __GFP_NOWARN);
static const unsigned int orders[] = {8, 4, 0};
static const int num_orders = ARRAY_SIZE(orders);
--
1.9.1
Hi Cheeramvelil & Hilman,
I found this patch do not ACK into the kernel mainline, and there is an obvious logical error.
commit 7f00db6493e69a3b6b7b9929218b127c62e6a53b
Author: Vinil Cheeramvelil <vinil.cheeramvelil(a)intel.com>
Date: Wed Jul 8 10:35:06 2015 +0800
ion: Handle the memory mapping correctly on x86
This patch modifies the ion page pool code to address
limitation in x86 PAT. When one physical page is mapped
to multiple virtual pages, the same cache policy
should be used. Add set_memory_wc/uc call to avoid aliases.
If not, all mappings will be cached(write back).
Change-Id: I98ee8902df0c80135dddfa998c4ca4c2bb44e40e
Signed-off-by: Zhebin Jin <zhebin.jin(a)intel.com>
Signed-off-by: Vinil Cheeramvelil <vinil.cheeramvelil(a)intel.com>
diff --git a/drivers/staging/android/ion/ion_system_heap.c b/drivers/staging/android/ion/ion_system_heap.c
index da2a63c..1f9feb7 100644
--- a/drivers/staging/android/ion/ion_system_heap.c
+++ b/drivers/staging/android/ion/ion_system_heap.c
@@ -85,8 +85,10 @@ static void free_buffer_page(struct ion_system_heap *heap,
if (!cached && !(buffer->private_flags & ION_PRIV_FLAG_SHRINKER_FREE)) {
struct ion_page_pool *pool = heap->pools[order_to_index(order)];
-
- ion_page_pool_free(pool, page);
+ if (buffer->private_flags & ION_PRIV_FLAG_SHRINKER_FREE)
+ ion_page_pool_free_immediate(pool, page);
+ else
+ ion_page_pool_free(pool, page);
the if else here is totally redundant
} else {
__free_pages(page, order);
}
Currently CMakeLists.txt searches only for libftdi but on platforms
where libftdi may be parallel installed this is insufficient. Fix
the package detection and ensure we apply the detection results to
the default build arguments.
Also removes the check for libusb; 96boardsctl.c does not directly use
this library so we can rely on pkg-config to get the link line right.
Signed-off-by: Daniel Thompson <daniel.thompson(a)linaro.org>
---
96boardsctl/CMakeLists.txt | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/96boardsctl/CMakeLists.txt b/96boardsctl/CMakeLists.txt
index a55852894f95..2e74c4e63de2 100644
--- a/96boardsctl/CMakeLists.txt
+++ b/96boardsctl/CMakeLists.txt
@@ -8,10 +8,18 @@ configure_file ("${PROJECT_SOURCE_DIR}/config.h.in" "${PROJECT_BINARY_DIR}/confi
include_directories ("${PROJECT_BINARY_DIR}")
find_package(PkgConfig)
-pkg_check_modules(PC_LIBS REQUIRED libusb libftdi)
+
+pkg_check_modules(LIBFTDI libftdi1)
+if (NOT LIBFTDI_FOUND)
+ pkg_check_modules(LIBFTDI REQUIRED libftdi)
+endif()
+
+include_directories(${LIBFTDI_INCLUDE_DIRS})
+link_directories(${LIBFTDI_LIBRARY_DIRS})
+add_definitions(${LIBFTDI_CFLAGS_OTHER})
add_executable(96boardsctl 96boardsctl.c)
-target_link_libraries(96boardsctl usb ftdi)
+target_link_libraries(96boardsctl ${LIBFTDI_LIBRARIES})
install (TARGETS 96boardsctl DESTINATION bin)
install (FILES udev-rules/71-ftdi_sio.rules DESTINATION etc/udev/rules.d)
--
2.5.0
Since ion alloc can be called by userspace,eg gralloc.
When it is called frequently, the efficiency of kswapd is
to low. And the reclaimed memory is too lower. In this way,
the kswapd can use to much cpu resources.
With 3.5GB DMA Zone and 0.5 Normal Zone.
pgsteal_kswapd_dma 9364140
pgsteal_kswapd_normal 7071043
pgscan_kswapd_dma 10428250
pgscan_kswapd_normal 37840094
With this change the reclaim ratio has greatly improved
18.9% -> 72.5%
Signed-off-by: Chen Feng <puck.chen(a)hisilicon.com>
Signed-off-by: Lu bing <albert.lubing(a)hisilicon.com>
---
drivers/staging/android/ion/ion_system_heap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/android/ion/ion_system_heap.c b/drivers/staging/android/ion/ion_system_heap.c
index d4c3e55..b69dfc7 100644
--- a/drivers/staging/android/ion/ion_system_heap.c
+++ b/drivers/staging/android/ion/ion_system_heap.c
@@ -27,7 +27,7 @@
#include "ion_priv.h"
static gfp_t high_order_gfp_flags = (GFP_HIGHUSER | __GFP_ZERO | __GFP_NOWARN |
- __GFP_NORETRY) & ~__GFP_DIRECT_RECLAIM;
+ __GFP_NORETRY) & ~__GFP_RECLAIM;
static gfp_t low_order_gfp_flags = (GFP_HIGHUSER | __GFP_ZERO | __GFP_NOWARN);
static const unsigned int orders[] = {8, 4, 0};
static const int num_orders = ARRAY_SIZE(orders);
--
1.9.1
After Rob pointed out there's a non-ancient version of the
devicetree bindings for pstore/ramoops, I figured it would be
worth migrating over to using it.
So this series adds pstore/ramoops support to hikey, and its
much more tidy compared to the last patch for this.
Would love any extra feedback and review.
The reserved ramoops address is mostly chosen at random, and
while the bootloader doesn't seen to clear that memory, I suspect
we will need a change to make sure that memory is protected by
the bootloader and UEFI applications don't scribble over it. So
help there would be appreciated!
thanks
-john
Cc: Rob Herring <rob.herring(a)linaro.org>
Cc: Arnd Bergmann <arnd.bergmann(a)linaro.org>
Cc: Haojian Zhuang <haojian.zhuang(a)linaro.org>
Cc: Guodong Xu <guodong.xu(a)linaro.org>
Cc: Vishal Bhoj <vishal.bhoj(a)linaro.org>
Greg Hackmann (1):
pstore-ram: add Device Tree bindings
John Stultz (1):
hikey: dts: Add pstore support for HiKey
Documentation/ramoops.txt | 6 +-
arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 13 +++
arch/arm64/configs/hikey_defconfig | 7 ++
fs/pstore/ram.c | 114 ++++++++++++++++++++++++-
4 files changed, 134 insertions(+), 6 deletions(-)
--
1.9.1
Hi,
> 在 2015年12月31日，22:48，Arnd Bergmann <arnd(a)arndb.de> 写道：
>>
>>> So in case of 4K pages, the minimum amount of free memory is 3MB, and
>>> almost always there are less than 8 MB free, . This is expected.
>>>
>>> In contrast, for the 64KB page case, we never have less than 512MB
>>> RAM free, and it's usually between 512 and 520MB, which is very surprising
>>> and indicates that there is a bug somewhere, either in the accounting
>>> or in the code in mm/page_alloc.c that tries to reserve some RAM for
>>> __GFP_HIGH allocations. Can you have a look at that code?
>>>
>>
The root cause is that CMA reserved 512M memory in 64K page size, and buddy allocator
can not eat those memory. Some guys explain that ext4 filesystem don’t support
migration page well, I didn’t dig into it yet. After unset CONFIG_CMA, the free memory
can down to very low in 64K page size.
Besides that, I found some weird problems in db410c.
1. there is no ZONE_NORMAL, only ZONE_DMA. I don’t know if there are bad influences,
or bug in zone_sizes_init(). I have try to hard code max_dma to 64M in zone_sizes_init(),
and it works.
2. 512M CMA memory in 64K page. Is the number normal? As I know, 4K page size only
have 64M CMA memory. I have tracked the code, and found that the size passed to
cma_declare_contiguous() function is the same as 4K page, but after call ALIGN(), the
size increase to 512M.
3. As the test data indicated, CMA memory in 4K page can be consumed, but in 64K page,
the result is not the same. A bug here?
Pingbo
Hi,
Does anyone run KASan on db410c successfully? I merged arm64-upstream branch
over integration-linux-qcomlt, and enable KASan feature, compiled with gcc 5.1.
But the kernel hanged before start_kernel(), no log output.
Please tell me if I miss something here.
Pingbo
