hi all,
I'm getting a 2-order page allocation failure problem on 4.1.18.
>From the Mem-info, it seems the system have much zero order free pages which
>can be used for memory compaction.
Is it possible that the memory compacted by current process used by other
process soon, which cause page
On 2016/7/19 22:14, Vlastimil Babka wrote:
> On 07/19/2016 03:48 PM, Xishi Qiu wrote:
>> On 2016/7/19 21:17, Vlastimil Babka wrote:
>>
>>> On 07/19/2016 02:43 PM, Yisheng Xie wrote:
>>>> hi all,
>>>> I'm getting a 2-order page allocation f
lated count mismatch, as Minchan Kim's
suggestion.
v2:
* delete function soft_offline_movable_page() and hanle non-lru movable
page in __soft_offline_page() as Michal Hocko suggested.
Yisheng Xie (4):
mm/migration: make isolate_movable_page() return int type
mm/migration: make isolate
migration.
This patch straightforwardly adds non-lru migration code, which means
adding non-lru related code to the functions which scan over pfn and
collect pages to be migrated and isolate them before migration.
Signed-off-by: Yisheng Xie <xieyishe...@huawei.com>
Cc: Michal Hocko <mho...@kern
Define isolate_movable_page as a static inline function when
CONFIG_MIGRATION is not enable. It should return -EBUSY here which means
failed to isolate movable pages.
This patch do not have any functional change but prepare for later patch.
Signed-off-by: Yisheng Xie <xieyishe...@huawei.
to another page and disable
the original (maybe half-broken) one.
Signed-off-by: Yisheng Xie <xieyishe...@huawei.com>
Suggested-by: Michal Hocko <mho...@kernel.org>
Suggested-by: Minchan Kim <minc...@kernel.org>
Reviewed-by: Minchan Kim <minc...@kernel.org>
Acked-by: Naoya Ho
Change the return type of isolate_movable_page() from bool to int. It
will return 0 when isolate movable page successfully, and return -EBUSY
when it isolates failed.
There is no functional change within this patch but prepare for later
patch.
Signed-off-by: Yisheng Xie <xieyishe...@huawei.
irtio_rng with CONFIG_VMAP_STACK=y?
Could you please give me more info. about it.
Really thanks for that!
Yisheng Xie.
>
> Reported-by: Matt Mullins <mmull...@mmlx.us>
> Tested-by: Matt Mullins <mmull...@mmlx.us>
> Fixes: d3cc7996473a ("hwrng: fetch randomness only aft
.@gmail.com>
Cc: Nitin Gupta <ngu...@vflare.org>
Cc: Hanjun Guo <guohan...@huawei.com>
Signed-off-by: Yisheng Xie <xieyishe...@huawei.com>
---
mm/zsmalloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index 9cc3c0b..
The class index and fullness group are not encoded in (first)page->mapping
any more, after commit 3783689a1aa8 ("zsmalloc: introduce zspage
structure"). Instead, they are store in struct zspage. Just delete this
unneeded comment.
Signed-off-by: Yisheng Xie <xieyishe...@huawe
, ys...@foxmail.com wrote:
>>>> From: Yisheng Xie <xieyishe...@huawei.com>
>>>>
>>>> This patch changes the return type of isolate_movable_page()
>>>> from bool to int. It will return 0 when isolate movable page
>>>> successfully, retu
17 15:48:21, Minchan Kim wrote:
>>>>> Hi Yisheng,
>>>>>
>>>>> On Tue, Jan 31, 2017 at 09:06:18PM +0800, ys...@foxmail.com wrote:
>>>>>> From: Yisheng Xie <xieyishe...@huawei.com>
>>>>>>
>>>>&g
With CONFIG_BALLOON_COMPACTION=y, it will mount balloon_mnt for
balloon page migration when probe a virtio_balloon device, however
do not unmount it when remove the device, fix it.
Fixes: b1123ea6d3b3 ("mm: balloon: use general non-lru movable page feature")
Signed-off-by: Yisheng Xie
hi, Matt,
Thanks for your reply.
On 2017/2/4 12:34, Matt Mullins wrote:
> On Sat, Feb 04, 2017 at 11:47:38AM +0800, Yisheng Xie wrote:
>> On 2016/10/18 1:06, Andy Lutomirski wrote:
>>> hw_random carefully avoids using a stack buffer except in
>>> add_early_randomn
Hi Naoya Horiguchi,
Thanks for reviewing.
On 2017/2/6 11:29, Naoya Horiguchi wrote:
> On Fri, Feb 03, 2017 at 03:59:30PM +0800, Yisheng Xie wrote:
>> We had considered all of the non-lru pages as unmovable before commit
>> bda807d44454 ("mm: migrate: support non-lru mo
Hi Minchan,
Thanks for reviewing.
On 2017/1/23 13:14, Minchan Kim wrote:
> Hello,
>
> On Thu, Jan 19, 2017 at 10:59:03PM +0800, ys...@foxmail.com wrote:
>> From: Yisheng Xie <xieyishe...@huawei.com>
>>
>> @@ -1527,7 +1527,8 @@ static int get_any_page(struct page
hi,
sorry to disturb, I will send another version to make a minor change
about page_lock checking in scan_movable_pages.
On 2017/1/25 11:25, Yisheng Xie wrote:
> We had considered all of the non-lru pages as unmovable before
> commit bda807d44454 ("mm: migrate: support non-lru m
migration.
This patch straightforwardly add non-lru migration code, which
means adding non-lru related code to the functions which scan
over pfn and collect pages to be migrated and isolate them before
migration.
Signed-off-by: Yisheng Xie <xieyishe...@huawei.com>
---
v2
make a minor change about
Hi， Michal，
Sorry for late reply.
On 01/26/2017 05:18 PM, Michal Hocko wrote:
> On Wed 25-01-17 23:05:37, ys...@foxmail.com wrote:
>> From: Yisheng Xie <xieyishe...@huawei.com>
>>
>> Define isolate_movable_page as a static inline function when
>> CONFIG_MIGRATIO
Hi, Michal,
Sorry for late reply.
On 01/26/2017 05:27 PM, Michal Hocko wrote:
> On Wed 25-01-17 23:05:38, ys...@foxmail.com wrote:
>> From: Yisheng Xie <xieyishe...@huawei.com>
>>
>> This patch is to extends soft offlining framework to support
>> non-lru page
hi Michal,
Thank you for reviewing and sorry for late reply.
On 01/26/2017 05:43 PM, Michal Hocko wrote:
> On Wed 25-01-17 14:59:45, Yisheng Xie wrote:
>
> static unsigned long scan_movable_pages(unsigned long start, unsigned long
> end)
> {
> @@ -1531,6 +1531,16 @@ st
lease help to review it ? Thanks so much~
I am so sorry about that.
Thanks.
Yisheng Xie
On 2017/1/25 18:36, Yisheng Xie wrote:
> Define isolate_movable_page as a static inline function when
> CONFIG_MIGRATION is not enable. It should return false
> here which means failed to isolate movable pag
r non-lru
movable page" with CONFIG_MIGRATION disabled.
Signed-off-by: Yisheng Xie <xieyishe...@huawei.com>
---
include/linux/migrate.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/migrate.h b/include/linux/migrate.h
index ae8d475..631a8c8 100644
--- a/include
Hi, Michal,
Thanks for reviewing.
On 01/25/2017 08:01 PM, Michal Hocko wrote:
> On Wed 25-01-17 18:36:03, Yisheng Xie wrote:
>> Define isolate_movable_page as a static inline function when
>> CONFIG_MIGRATION is not enable. It should return false
>> here which means fail
migration.
This patch straightforwardly add non-lru migration code, which
means adding non-lru related code to the functions which scan
over pfn and collect pages to be migrated and isolate them before
migration.
Signed-off-by: Yisheng Xie <xieyishe...@huawei.com>
---
mm/memor
the following memmap variants:
- memmap=nn[KMG]$ss[KMG]: mark specified memory as reserved;
- memmap=nn[KMG]@ss[KMG]: force usage of a specific region of memory;
Reported-by: Bob Dong <dong...@huawei.com>
Signed-off-by: Yisheng Xie <xieyishe...@huawei.com>
---
arch/arm64/mm
the pages in zspage and
init the page->freelist as NULL for last page, so no need to use
PG_Private_2 anymore.
This patch is to remove redundant SetPagePrivate2 in create_page_chain
and ClearPagePrivate2 in reset_page(). Maybe can save few cycles for
migration of zsmalloc page :)
Signed-off-by:
hi Michal,
Thanks for your comment.
On 2017/2/9 21:41, Michal Hocko wrote:
> On Thu 09-02-17 14:26:28, Michal Hocko wrote:
>> On Thu 09-02-17 20:54:49, Yisheng Xie wrote:
>>> Hi all,
>>> I get an oom on a linux 3.10 kvm guest OS. when it triggers the oom
>>> it
Hi Michal,
Thanks for comment!
On 2017/2/10 15:09, Michal Hocko wrote:
> On Fri 10-02-17 09:13:58, Yisheng Xie wrote:
>> hi Michal,
>> Thanks for your comment.
>>
>> On 2017/2/9 21:41, Michal Hocko wrote:
>>> On Thu 09-02-17 14:26:28, Michal Hocko wrote:
>&g
Hi Michal,
Thanks for comment!
On 2017/2/10 16:52, Michal Hocko wrote:
> On Fri 10-02-17 16:48:58, Yisheng Xie wrote:
>> Hi Michal,
>>
>> Thanks for comment!
>> On 2017/2/10 15:09, Michal Hocko wrote:
>>> On Fri 10-02-17 09:13:58, Yisheng Xie wrote:
>>
and have any idea about it?
Any comment is more than welcome!
Thanks
Yisheng Xie
-
[ 81.234289] DefSch0200 invoked oom-killer: gfp_mask=0xd0, order=0,
oom_score_adj=0
[ 81.234295] DefSch0200 cpuset=/ mems_allowed=0
[ 81.234299] CPU: 3 PID: 8284 Comm: DefSch0200 Tainted: G
On 2017/1/18 17:51, Michal Hocko wrote:
> On Wed 18-01-17 12:00:54, Yisheng Xie wrote:
>> This patch is to extends soft offlining framework to support
>> non-lru page, which already support migration after
>> commit bda807d44454 ("mm: migrate: support non-lru
migrating data onto another
page and disable the original (maybe half-broken) one.
Signed-off-by: Yisheng Xie <xieyishe...@huawei.com>
---
mm/memory-failure.c | 55 +++--
1 file changed, 53 insertions(+), 2 deletions(-)
diff --git a/mm/memor
Hi Naoya,
On 2017/1/18 17:45, Naoya Horiguchi wrote:
> On Wed, Jan 18, 2017 at 12:00:54PM +0800, Yisheng Xie wrote:
>> This patch is to extends soft offlining framework to support
>> non-lru page, which already support migration after
>> commit bda807d44454 ("mm: migrat
add more,
hi all,
Could anyone do me a favor and give some comments?
Thanks
Xie Yisheng
On 2016/8/18 20:05, Xie Yisheng wrote:
> As we know, arm64 also support gigantic hugepage eg. 1G.
> So I try to use this function by adding hugepagesz=1G
> in kernel parameters, with CONFIG_CMA=y.
> However,
On 2016/8/19 18:25, Michal Hocko wrote:
> On Thu 18-08-16 20:05:29, Xie Yisheng wrote:
>> As we know, arm64 also support gigantic hugepage eg. 1G.
>
> Well, I do not know that. How can I check?
>
Hi Michal,
Thank you for your reply.
Maybe you can check the setup_hugepagesz()
in
On 2016/8/22 18:00, Catalin Marinas wrote:
> On Mon, Aug 22, 2016 at 10:03:58AM +0200, Michal Hocko wrote:
>> On Mon 22-08-16 10:56:43, Xie Yisheng wrote:
>>> Arm64 supports gigantic page after
>>> commit 084bd29810a5 ("ARM64: mm: HugeTLB support.")
>>> however, it got broken by
>>> commit
On 2016/8/22 16:01, Michal Hocko wrote:
> On Mon 22-08-16 10:56:42, Xie Yisheng wrote:
>>
>> +config ARCH_HAS_GIGANTIC_PAGE
>> +depends on HUGETLB_PAGE
>> +bool
>> +
>
> but is this really necessary? The code where we use
> ARCH_HAS_GIGANTIC_PAGE already depends on HUGETLB_PAGE.
>
Hi
We added supporting for PUD-sized transparent hugepages, however count
the event "thp split pud" into thp_split_pmd event.
To clarify the event count of thp split pud from pmd, this patch add a
new event named thp_split_pud.
Signed-off-by: Yisheng Xie <xieyishe...@huawei.com>
--
Hi Ard,
Thanks for comment.
On 2017/2/26 18:46, Ard Biesheuvel wrote:
> On 25 February 2017 at 06:47, Yisheng Xie <xieyishe...@huawei.com> wrote:
>> When use device tree mode, user can reserve memory by changes the dts,
>> however, when boot with ACPI, user cannot
hi Mark,
Thanks for comment
On 2017/2/27 16:48, Mark Rutland wrote:
> Hi,
>
> On Mon, Feb 27, 2017 at 11:48:50AM +0800, Yisheng Xie wrote:
>> On 2017/2/26 18:46, Ard Biesheuvel wrote:
>>> On 25 February 2017 at 06:47, Yisheng Xie <xieyishe...@huawei.com> wrote
Hi all,
Could someone help to give some comments?
Really thanks for that.
Thanks.
Xie Yisheng
On 2016/9/2 18:26, Will Deacon wrote:
> On Fri, Sep 02, 2016 at 06:18:39PM +0800, Xie Yisheng wrote:
>> From: Yisheng Xie <xieyishe...@huawei.com>
>>
>> There's an early me
On 2016/9/5 21:57, Matt Fleming wrote:
> On Fri, 02 Sep, at 11:26:18AM, Will Deacon wrote:
>> On Fri, Sep 02, 2016 at 06:18:39PM +0800, Xie Yisheng wrote:
>>> From: Yisheng Xie <xieyishe...@huawei.com>
>>>
>>> diff --git a/drivers/firmware/efi/arm-ini
chal Hocko <mho...@suse.com>
Acked-by: Catalin Marinas <catalin.mari...@arm.com>
Signed-off-by: Yisheng Xie <xieyishe...@huawei.com>
---
arch/arm64/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index bc3f00f..92217f6 100644
--
time for arch arm64,
with CONFIG_CMA=y or other related configs is enabled.
You can see the former discussions at:
https://lkml.org/lkml/2016/8/18/310
https://lkml.org/lkml/2016/8/21/410
https://lkml.org/lkml/2016/8/22/319
Yisheng Xie (2):
mm/hugetlb: Introduce ARCH_HAS_GIGANTIC_PAGE
arm64 Kcon
Avoid making ifdef get pretty unwieldy if many ARCHs support gigantic page.
No functional change with this patch.
Signed-off-by: Yisheng Xie <xieyishe...@huawei.com>
Suggested-by: Michal Hocko <mho...@suse.com>
Acked-by: Michal Hocko <mho...@suse.com>
Acked-by: Naoya H
ike i386, it failed for no such sysfs.
To make sysfs soft_offline_page usable once MEMORY_FAILURE is enabled,
this patch introduces CONFIG_MEMORY_DEVICE, and selects it when
MEMORY_FAILURE or MEMORY_HOTPLUG_SPARSE is enabled.
Signed-off-by: Yisheng Xie <xieyishe...@huawei.com>
---
driver
hi all,
When I enable NUMA in BIOS for arm64, it failed to boot on
v4.8-rc4-162-g071e31e.
For the crash log, it seems caused by error number of cpumask.
Any ideas about it?
Thanks.
The related config and detail dmesg can be seen in the attachment.
--- crash messages ---
[1.279155]
On 2016/9/13 19:18, Matt Fleming wrote:
> On Wed, 07 Sep, at 07:15:48PM, Yisheng Xie wrote:
>>
>>
>> On 2016/9/5 21:57, Matt Fleming wrote:
>>> On Fri, 02 Sep, at 11:26:18AM, Will Deacon wrote:
>>>> On Fri, Sep 02, 2016 at 06:18:39PM +0800, Xie Yishen
On 2016/9/19 22:07, Mark Rutland wrote:
> [adding LAKML, arm64 maintainers]
>
> On Mon, Sep 19, 2016 at 09:05:26PM +0800, Yisheng Xie wrote:
>> hi all,
>
> Can you modify the warning in cpumask.h to dump the bad CPU number? That
> would make it fairly clear if that's
On 2016/9/20 10:01, Ming Lei wrote:
> On Mon, Sep 19, 2016 at 9:05 PM, Yisheng Xie <xieyishe...@huawei.com> wrote:
>> hi all,
>> When I enable NUMA in BIOS for arm64, it failed to boot on
>> v4.8-rc4-162-g071e31e.
>> For the crash log, it seems caused by erro
3464] ---[ end trace 58c0cd36b88802bc ]---
> [2.608138] Kernel panic - not syncing: Fatal exception
>
> Fix by supplying a cpu_to_node() implementation that returns correct
> node mappings.
>
> Cc: <sta...@vger.kernel.org> # 4.7.x-
> Signed-off-by: David Daney <david.da.
There's an early memmap leak in efi_init error path, fix it.
Signed-off-by: Yisheng Xie <xieyishe...@huawei.com>
---
drivers/firmware/efi/arm-init.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
tion call,
> simplify by removing the function and out-lining its contents.
>
> Suggested-by: Robert Richter <r...@kernel.org>
> fixes: 1a2db300348b ("arm64, numa: Add NUMA support for arm64 platforms.")
> Cc: <sta...@vger.kernel.org> # 4.7.x-
> Signed-off-by:
Hi Andrew,
Can this patchset be merged? Or have any other comments?
Thanks
Xie Yisheng
On 2016/8/26 18:26, Will Deacon wrote:
> On Mon, Aug 22, 2016 at 09:20:02PM +0800, Xie Yisheng wrote:
>>
>> Xie Yisheng (2):
>> mm/hugetlb: Introduce ARCH_HAS_GIGANTIC_PAGE
>> arm64 Kconfig: Select
Hi,
On 2016/10/19 6:07, Zheng, Lv wrote:
> Hi,
>
> I'm not sure what you mean.
> I mean you need ACPI_USE_SYSTEM_INTTYPES in case s64 has already been defined
> in that environment.
> Are you sure s64 should be defined for your environment?
>
s64 is not defined in my build environment but in
+ mm mail list
On 2016/10/10 19:26, Yisheng Xie wrote:
> MEMORY_FAILURE do not depend on SPARSEMEM_MANUAL,
> nor MEMORY_HOTPLUG_SPARSE. However, when I tried to use sysfs:
> /sys/devices/system/memory/soft_offline_page
> /sys/devices/system/memory/hard_offline_page
> to test
On 2016/10/22 3:40, Zheng, Lv wrote:
> Hi,
>
> I generated a solution with tools/power/acpi makefiles.
> Please give it a try.
Hi Lv,
Your patch also works.
> Sorry for the hackish build includes.
>
> Thanks and best regards
> Lv
>
Hi, Lv
On 2016/10/18 6:26, Zheng, Lv wrote:
> Hi, Yisheng
>
>> From: Yisheng Xie [mailto:xieyishe...@huawei.com]
>> Subject: [PATCH] ACPICA: arm64: fix compile apci tools fail for arm64
>>
>> when try to cross compile acpi tool in dir kernel/tools
>> for arm64
I tried to echo an invalid value to an unsigned long type sysctl on 4.9.0-rc6:
linux:~# cat /proc/sys/vm/user_reserve_kbytes
131072
linux:~# echo -1 > /proc/sys/vm/user_reserve_kbytes
linux:~# cat /proc/sys/vm/user_reserve_kbytes
131072
The echo operation got error and the value do
On 2016/10/14 18:53, Yisheng Xie wrote:
>
ping
Could someone help to give some comment? Really thanks for that.
Thanks.
Yisheng
>
> On 2016/10/10 19:26, Yisheng Xie wrote:
>> MEMORY_FAILURE do not depend on SPARSEMEM_MANUAL,
>> nor MEMORY_HOTPLUG_SPARSE. However
typedef signed long long s64;
^
Fix this compile problem.
Fixes: e323c02dee59 ("ACPICA: MSVC9: Fix inclusion order issue")
Signed-off-by: Yisheng Xie <xieyishe...@huawei.com>
---
include/acpi/platform/acenv.h | 4
1 file changed, 4 insertions(+)
diff
On 2016/11/27 7:15, subas...@codeaurora.org wrote:
> On 2016-11-26 02:13, Yisheng Xie wrote:
>> --
>> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
>> index 706309f..40e9285 100644
>> --- a/kernel/sysctl.c
>> +++ b/kernel/sysctl.c
>
Hi Robert,
We have merged your patch to 4.9.0-rc8, however we still meet the similar
problem
on our D05 board:
Thanks,
Yisheng Xie
-
[5.081971] [ cut here ]
[5.086668] kernel BUG at mm/page_alloc.c:1863!
[5.091281] Internal error: Oops - BUG: 0
On 2016/12/9 20:23, Hanjun Guo wrote:
> On 12/09/2016 08:19 PM, Ard Biesheuvel wrote:
>> On 9 December 2016 at 12:14, Yisheng Xie <xieyishe...@huawei.com> wrote:
>>> Hi Robert,
>>> We have merged your patch to 4.9.0-rc8, however we still meet the similar
hi Robert,
On 2016/12/10 2:10, Robert Richter wrote:
> On ThunderX systems with certain memory configurations we see the
> following BUG_ON():
>
> kernel BUG at mm/page_alloc.c:1848!
>
> This happens for some configs with 64k page size enabled. The BUG_ON()
> checks if start and end page of a
hi Robert,
On 2016/12/12 11:12, Yisheng Xie wrote:
> hi Robert,
>
> On 2016/12/10 2:10, Robert Richter wrote:
>> On ThunderX systems with certain memory configurations we see the
>> following BUG_ON():
>>
>> kernel BUG at mm/page_alloc.c:1848!
>>
>>
hi Robert,
On 2016/12/14 17:45, Robert Richter wrote:
> On 12.12.16 17:53:02, Yisheng Xie wrote:
>> It seems that memblock_is_memory() is also too strict for early_pfn_valid,
>> so what about this patch, which use common pfn_valid as early_pfn_valid
>> when CONFIG_
On 2016/11/30 17:18, Thomas Gleixner wrote:
> On Wed, 30 Nov 2016, Yisheng Xie wrote:
>
>> Hi all,
>> The kernel version is 4.1.18, and we got a panic at cascade().
>> from the log it seems cause by BUG_ON of kernel/time/timer.c:1120.
>> Any ideas about about it?
&
Hi all,
The kernel version is 4.1.18, and we got a panic at cascade().
from the log it seems cause by BUG_ON of kernel/time/timer.c:1120.
Any ideas about about it?
Any reply will be appreciated.
Thanks,
Yisheng.
-
[76661.805297s][pid:457,cpu3,surfaceflinger]CPU: 3 PID:
off-by: Yisheng Xie <xieyishe...@huawei.com>
---
This is a patchset after RFC, you can see the former discussion at
https://lkml.org/lkml/2016/11/26/48
Any comment is more than welcome.
Thanks,
Yisheng Xie.
---
kernel/sysctl.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
d
vent_etime
The patch adds the missing check in do_proc_douintvec_conv.
With the patch an overflow of unsigned int will result in an error
EINVAL when writing to the the sysctl file system.
Signed-off-by: Yisheng Xie <xieyishe...@huawei.com>
---
kernel/sysctl.c | 4
1 file chan
On 2016/12/1 5:33, Andrew Morton wrote:
> On Wed, 30 Nov 2016 18:30:52 +0800 Yisheng Xie <xieyishe...@huawei.com> wrote:
>
>> I tried to echo an invalid value to an unsigned long type sysctl on
>> 4.9.0-rc6:
>>linux:~# cat /proc/sys/vm/user_reserve_kbytes
>&
On 2016/12/3 3:24, Eric W. Biederman wrote:
> Yisheng Xie <xieyishe...@huawei.com> writes:
>
>> On 2016/12/1 5:33, Andrew Morton wrote:
>>> On Wed, 30 Nov 2016 18:30:52 +0800 Yisheng Xie <xieyishe...@huawei.com>
>>> wrote:
>>>
>>>
ad_acquire(>flags) & CSD_FLAG_LOCK)
cpu_relax();
}
Any comment is more than welcome!
Thanks,
Yisheng Xie
---
[ 1376.188273] NMI watchdog: BUG: soft lockup - CPU#1 stuck for 22s!
[kworker/u64:0:6]
[ 1376.206461]
[ 1376.218555] CPU: 1 PID: 6 Comm: kworker/u64:0 Tainte
From: Yisheng Xie <xieyishe...@huawei.com>
By reviewing code, I find that when enter do_try_to_free_pages, the
may_thrash is always clear, and it will retry shrink zones to tap
cgroup's reserves memory by setting may_thrash when the former
shrink_zones reclaim nothing.
However, when
why it happened. Any idea about it?
Any comment is more than welcome!
Thanks
Yisheng Xie
Hi Minchan,
Thanks for your comment!
On 2017/3/29 8:20, Minchan Kim wrote:
> Hello,
>
> On Tue, Mar 28, 2017 at 03:20:22PM +0800, Yisheng Xie wrote:
>> Hi, all,
>>
>> We had backport the no-lru migration to linux-4.1, meanwhile change the
>> ZS_MAX_ZSPAGE_ORDER t
Hi Sergey,
Thanks for your comment!
On 2017/3/29 14:42, Sergey Senozhatsky wrote:
> On (03/29/17 09:20), Minchan Kim wrote:
>> Hello,
>>
>> On Tue, Mar 28, 2017 at 03:20:22PM +0800, Yisheng Xie wrote:
>>> Hi, all,
>>>
>>> We had backport the
it if there is any memcg protected by low limit
and only do the retry when memcg_low_protection is set while may_thrash
is clear.
Signed-off-by: Yisheng Xie <xieyishe...@huawei.com>
Suggested-by: Michal Hocko <mho...@kernel.org>
Suggested-by: Shakeel Butt <shake...@google.com>
Reviewe
Hi Michal
Thanks for reviewing.
On 2017/3/15 20:41, Michal Hocko wrote:
> On Wed 15-03-17 19:36:48, Yisheng Xie wrote:
>> By reviewing code, I find that when enter do_try_to_free_pages, the
>> may_thrash is always clear, and it will retry shrink zones to tap
>> cgroup's reser
If the migrate target is a large free page and we ignore suitable,
it may not good for defrag. So move the ignore block suitable after
check large free page.
Signed-off-by: Yisheng Xie <xieyishe...@huawei.com>
---
mm/compaction.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Hi Vlastimil,
Thanks for comment.
On 2017/3/10 15:30, Vlastimil Babka wrote:
> On 03/10/2017 05:20 AM, Yisheng Xie wrote:
>> If the migrate target is a large free page and we ignore suitable,
>> it may not good for defrag. So move the ignore block suitable after
>>
From: Yisheng Xie <xieyishe...@huawei.com>
When we enter do_try_to_free_pages, the may_thrash is always clear, and
it will retry shrink zones to tap cgroup's reserves memory by setting
may_thrash when the former shrink_zones reclaim nothing.
However, when memcg is disabled or on legacy hie
From: Yisheng Xie <xieyishe...@huawei.com>
When we enter do_try_to_free_pages, the may_thrash is always clear, and
it will retry shrink zones to tap cgroup's reserves memory by setting
may_thrash when the former shrink_zones reclaim nothing.
However, when memcg is disabled or on legacy hie
nting out these.
>
> On Sun 12-03-17 19:06:10, Yisheng Xie wrote:
>> From: Yisheng Xie <xieyishe...@huawei.com>
>>
>> When we enter do_try_to_free_pages, the may_thrash is always clear, and
>> it will retry shrink zones to tap cgroup's reserves memory by setting
>> may_
Hi Vlastimil,
Thanks for comment.
On 2017/3/13 17:51, Vlastimil Babka wrote:
> On 03/10/2017 10:53 AM, Yisheng Xie wrote:
>> Hi Vlastimil,
>>
>> Thanks for comment.
>> On 2017/3/10 15:30, Vlastimil Babka wrote:
>>> On 03/10/2017 05:20 AM, Yisheng Xie wrote:
&
that this patch is just based on
logical analyses which might be better for future-proofing the function
and it is most likely won't have any visible effect right now, for
direct compaction shouldn't have to be called if there's a
>=pageblock_order page already available.
Signed-off-by: Yisheng Xie <xi
From: Yisheng Xie <xieyishe...@huawei.com>
When we enter do_try_to_free_pages, the may_thrash is always clear, and
it will retry shrink zones to tap cgroup's reserves memory by setting
may_thrash when the former shrink_zones reclaim nothing.
However, when memcg is disabled or on legacy hie
hi, Shakeel,
On 03/12/2017 01:52 AM, Shakeel Butt wrote:
> On Sat, Mar 11, 2017 at 5:51 AM, Yisheng Xie <ys...@foxmail.com> wrote:
>> From: Yisheng Xie <xieyishe...@huawei.com>
>>
>> When we enter do_try_to_free_pages, the may_thrash is always clear, and
>
Hi, Vlastimil,
On 2017/3/8 15:07, Vlastimil Babka wrote:
> On 03/08/2017 03:16 AM, Yisheng Xie wrote:
>> Hi Vlastimil ,
>>
>> On 2017/2/11 1:23, Vlastimil Babka wrote:
>>> @@ -1977,7 +1978,7 @@ static void steal_suitable_fallback(struct zone
>>> *zone,
Hi Shakeel,
Thanks for reviewing.
On 03/11/2017 11:40 AM, Shakeel Butt wrote:
> On Fri, Mar 10, 2017 at 6:19 PM, Yisheng Xie <ys...@foxmail.com> wrote:
>> From: Yisheng Xie <xieyishe...@huawei.com>
>>
>> When we enter do_try_to_free_pages, the may_thrash is a
From: Yisheng Xie <xieyishe...@huawei.com>
When we enter do_try_to_free_pages, the may_thrash is always clear, and
it will retry shrink zones to tap cgroup's reserves memory by setting
may_thrash when the former shrink_zones reclaim nothing.
However, if CONFIG_MEMCG=n, it should
uld be removed, if we can steal whole
block
then just do it. If not we can check whether we can set it as mixed mt, right?
Please let me know if I miss something..
Thanks
Yisheng Xie
> +
> + new_block_type = old_block_type = get_pageblock_migratetype(page);
> +
> /*
&g
Hi, Minchan
Thanks for your comment!
On 2017/8/14 16:08, Minchan Kim wrote:
> Hi Yisheng,
>
> Thanks for the all fixup!
> A minor nitpick below:
>
> On Fri, Aug 11, 2017 at 09:10:32AM +0800, Yisheng Xie wrote:
>> The compr_data_size is a stat for compressed size of pages
ZRAM_SAME means page consists the same element not the entirely zero page.
Signed-off-by: Yisheng Xie <xieyishe...@huawei.com>
---
drivers/block/zram/zram_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/block/zram/zram_drv.h b/drivers/block/zram/zram_drv.h
The compr_data_size is a stat for compressed size of pages stored, which
should be updated when we compresse a page.
Meanwhile fix a typo in comment:
* read_from_bdev_async() return 1 to avoid call page_endio() in zram_rw_page()
Signed-off-by: Yisheng Xie <xieyishe...@huawei.com>
---
Hi M
On 2017/8/14 17:34, Minchan Kim wrote:
> On Mon, Aug 14, 2017 at 05:24:16PM +0800, Yisheng Xie wrote:
>> Hi, Minchan
>>
>> Thanks for your comment!
>> On 2017/8/14 16:08, Minchan Kim wrote:
>>> Hi Yisheng,
>>>
>>> Thanks for the all fixup!
&
On 2017/8/11 10:07, Yisheng Xie wrote:
>
>
> On 2017/8/11 9:38, Sergey Senozhatsky wrote:
>> On (08/11/17 10:35), Sergey Senozhatsky wrote:
>>> On (08/11/17 09:10), Yisheng Xie wrote:
>>>> The compr_data_size is a stat for compressed size of pages stored, wh
On 2017/8/11 9:38, Sergey Senozhatsky wrote:
> On (08/11/17 10:35), Sergey Senozhatsky wrote:
>> On (08/11/17 09:10), Yisheng Xie wrote:
>>> The compr_data_size is a stat for compressed size of pages stored, which
>>> should add comp_len when we compresse a page.
1 - 100 of 805 matches
Mail list logo
