From: Michal Hocko <mhocko@kernel.org>
To: Reza Arbab <arbab@linux.vnet.ibm.com>
Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
Mel Gorman <mgorman@suse.de>, Vlastimil Babka <vbabka@suse.cz>,
Andrea Arcangeli <aarcange@redhat.com>,
Yasuaki Ishimatsu <yasu.isimatu@gmail.com>,
Tang Chen <tangchen@cn.fujitsu.com>,
qiuxishi@huawei.com, Kani Toshimitsu <toshi.kani@hpe.com>,
slaoub@gmail.com, Joonsoo Kim <js1304@gmail.com>,
Andi Kleen <ak@linux.intel.com>,
Zhang Zhen <zhenzhang.zhang@huawei.com>,
David Rientjes <rientjes@google.com>,
Daniel Kiper <daniel.kiper@oracle.com>,
Igor Mammedov <imammedo@redhat.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/6] mm: remove return value from init_currently_empty_zone
Date: Tue, 4 Apr 2017 09:30:56 +0200 [thread overview]
Message-ID: <20170404073056.GB15132@dhcp22.suse.cz> (raw)
In-Reply-To: <20170403212232.s3zynq2hh6hpnefr@arbab-laptop>
On Mon 03-04-17 16:22:32, Reza Arbab wrote:
> On Thu, Mar 30, 2017 at 01:54:51PM +0200, Michal Hocko wrote:
> >init_currently_empty_zone doesn't have any error to return yet it is
> >still an int and callers try to be defensive and try to handle potential
> >error. Remove this nonsense and simplify all callers.
>
> Semi-related; arch_remove_memory() returns int, but callers ignore it.
>
> Is that worth cleaning up? If so, should the implementations be simplified,
> or should we maybe do a pr_error() or something with it?
No, pr_error is not really helpful. Either that path can fail and we
should handle it properly - which will be hard because remove_memory
cannot handle that or we should just make arch_remove_memory
non-failing. I have a suspicion that this path doesn't really fail
in fact. This requires a deeper inspection though. I've put that on my
todo list.
Thanks!
--
Michal Hocko
SUSE Labs
WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org>
To: Reza Arbab <arbab@linux.vnet.ibm.com>
Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
Mel Gorman <mgorman@suse.de>, Vlastimil Babka <vbabka@suse.cz>,
Andrea Arcangeli <aarcange@redhat.com>,
Yasuaki Ishimatsu <yasu.isimatu@gmail.com>,
Tang Chen <tangchen@cn.fujitsu.com>,
qiuxishi@huawei.com, Kani Toshimitsu <toshi.kani@hpe.com>,
slaoub@gmail.com, Joonsoo Kim <js1304@gmail.com>,
Andi Kleen <ak@linux.intel.com>,
Zhang Zhen <zhenzhang.zhang@huawei.com>,
David Rientjes <rientjes@google.com>,
Daniel Kiper <daniel.kiper@oracle.com>,
Igor Mammedov <imammedo@redhat.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/6] mm: remove return value from init_currently_empty_zone
Date: Tue, 4 Apr 2017 09:30:56 +0200 [thread overview]
Message-ID: <20170404073056.GB15132@dhcp22.suse.cz> (raw)
In-Reply-To: <20170403212232.s3zynq2hh6hpnefr@arbab-laptop>
On Mon 03-04-17 16:22:32, Reza Arbab wrote:
> On Thu, Mar 30, 2017 at 01:54:51PM +0200, Michal Hocko wrote:
> >init_currently_empty_zone doesn't have any error to return yet it is
> >still an int and callers try to be defensive and try to handle potential
> >error. Remove this nonsense and simplify all callers.
>
> Semi-related; arch_remove_memory() returns int, but callers ignore it.
>
> Is that worth cleaning up? If so, should the implementations be simplified,
> or should we maybe do a pr_error() or something with it?
No, pr_error is not really helpful. Either that path can fail and we
should handle it properly - which will be hard because remove_memory
cannot handle that or we should just make arch_remove_memory
non-failing. I have a suspicion that this path doesn't really fail
in fact. This requires a deeper inspection though. I've put that on my
todo list.
Thanks!
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2017-04-04 7:31 UTC|newest]
Thread overview: 140+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-30 11:54 [PATCH 0/6] mm: make movable onlining suck less Michal Hocko
2017-03-30 11:54 ` Michal Hocko
2017-03-30 11:54 ` [PATCH 1/6] mm: get rid of zone_is_initialized Michal Hocko
2017-03-30 11:54 ` Michal Hocko
2017-03-31 3:39 ` Hillf Danton
2017-03-31 3:39 ` Hillf Danton
2017-03-31 6:43 ` Michal Hocko
2017-03-31 6:43 ` Michal Hocko
2017-03-31 6:48 ` Michal Hocko
2017-03-31 6:48 ` Michal Hocko
2017-03-31 7:39 ` [PATCH v1 " Michal Hocko
2017-03-31 7:39 ` Michal Hocko
2017-04-05 8:14 ` Michal Hocko
2017-04-05 8:14 ` Michal Hocko
2017-04-05 9:06 ` Igor Mammedov
2017-04-05 9:06 ` Igor Mammedov
2017-04-05 9:23 ` Michal Hocko
2017-04-05 9:23 ` Michal Hocko
2017-03-30 11:54 ` [PATCH 2/6] mm, tile: drop arch_{add,remove}_memory Michal Hocko
2017-03-30 11:54 ` Michal Hocko
2017-03-30 15:41 ` Chris Metcalf
2017-03-30 15:41 ` Chris Metcalf
2017-03-30 11:54 ` [PATCH 3/6] mm: remove return value from init_currently_empty_zone Michal Hocko
2017-03-30 11:54 ` Michal Hocko
2017-03-31 3:49 ` Hillf Danton
2017-03-31 3:49 ` Hillf Danton
2017-03-31 6:49 ` Michal Hocko
2017-03-31 6:49 ` Michal Hocko
2017-03-31 7:06 ` Hillf Danton
2017-03-31 7:06 ` Hillf Danton
2017-03-31 7:18 ` Michal Hocko
2017-03-31 7:18 ` Michal Hocko
2017-03-31 7:43 ` Michal Hocko
2017-03-31 7:43 ` Michal Hocko
2017-04-03 21:22 ` Reza Arbab
2017-04-03 21:22 ` Reza Arbab
2017-04-04 7:30 ` Michal Hocko [this message]
2017-04-04 7:30 ` Michal Hocko
2017-03-30 11:54 ` [PATCH 4/6] mm, memory_hotplug: use node instead of zone in can_online_high_movable Michal Hocko
2017-03-30 11:54 ` Michal Hocko
2017-03-30 11:54 ` [PATCH 5/6] mm, memory_hotplug: do not associate hotadded memory to zones until online Michal Hocko
2017-03-30 11:54 ` Michal Hocko
2017-03-31 6:18 ` Hillf Danton
2017-03-31 6:18 ` Hillf Danton
2017-03-31 6:50 ` Michal Hocko
2017-03-31 6:50 ` Michal Hocko
2017-04-04 12:21 ` Tobias Regnery
2017-04-04 12:21 ` Tobias Regnery
2017-04-04 12:45 ` Michal Hocko
2017-04-04 12:45 ` Michal Hocko
2017-04-06 8:14 ` Michal Hocko
2017-04-06 8:14 ` Michal Hocko
2017-04-06 12:46 ` Michal Hocko
2017-04-06 12:46 ` Michal Hocko
2017-03-30 11:54 ` [PATCH 6/6] mm, memory_hotplug: remove unused cruft after memory hotplug rework Michal Hocko
2017-03-30 11:54 ` Michal Hocko
2017-03-31 7:46 ` Michal Hocko
2017-03-31 7:46 ` Michal Hocko
2017-03-31 19:19 ` [PATCH 0/6] mm: make movable onlining suck less Heiko Carstens
2017-03-31 19:19 ` Heiko Carstens
2017-04-03 7:34 ` Michal Hocko
2017-04-03 7:34 ` Michal Hocko
2017-04-03 11:55 ` Michal Hocko
2017-04-03 11:55 ` Michal Hocko
2017-04-03 12:20 ` Igor Mammedov
2017-04-03 12:20 ` Igor Mammedov
2017-04-03 19:58 ` Reza Arbab
2017-04-03 19:58 ` Reza Arbab
2017-04-03 20:23 ` Michal Hocko
2017-04-03 20:23 ` Michal Hocko
2017-04-03 20:42 ` Reza Arbab
2017-04-03 20:42 ` Reza Arbab
2017-04-04 7:23 ` Michal Hocko
2017-04-04 7:23 ` Michal Hocko
2017-04-04 7:34 ` Michal Hocko
2017-04-04 7:34 ` Michal Hocko
2017-04-04 8:23 ` Michal Hocko
2017-04-04 8:23 ` Michal Hocko
2017-04-04 15:59 ` Reza Arbab
2017-04-04 15:59 ` Reza Arbab
2017-04-04 16:02 ` Reza Arbab
2017-04-04 16:02 ` Reza Arbab
2017-04-04 16:44 ` Michal Hocko
2017-04-04 16:44 ` Michal Hocko
2017-04-04 18:30 ` Reza Arbab
2017-04-04 18:30 ` Reza Arbab
2017-04-04 19:41 ` Michal Hocko
2017-04-04 19:41 ` Michal Hocko
2017-04-04 21:43 ` Reza Arbab
2017-04-04 21:43 ` Reza Arbab
2017-04-05 6:42 ` Michal Hocko
2017-04-05 6:42 ` Michal Hocko
2017-04-05 9:24 ` Michal Hocko
2017-04-05 9:24 ` Michal Hocko
2017-04-05 14:53 ` Reza Arbab
2017-04-05 14:53 ` Reza Arbab
2017-04-05 15:42 ` Michal Hocko
2017-04-05 15:42 ` Michal Hocko
2017-04-05 17:32 ` Reza Arbab
2017-04-05 17:32 ` Reza Arbab
2017-04-05 18:15 ` Michal Hocko
2017-04-05 18:15 ` Michal Hocko
2017-04-05 19:39 ` Michal Hocko
2017-04-05 19:39 ` Michal Hocko
2017-04-05 21:02 ` Michal Hocko
2017-04-05 21:02 ` Michal Hocko
2017-04-06 11:07 ` Michal Hocko
2017-04-06 11:07 ` Michal Hocko
2017-04-05 15:48 ` Reza Arbab
2017-04-05 15:48 ` Reza Arbab
2017-04-05 16:34 ` Michal Hocko
2017-04-05 16:34 ` Michal Hocko
2017-04-05 20:55 ` Reza Arbab
2017-04-05 20:55 ` Reza Arbab
2017-04-06 9:25 ` Michal Hocko
2017-04-06 9:25 ` Michal Hocko
2017-04-05 13:52 ` Michal Hocko
2017-04-05 13:52 ` Michal Hocko
2017-04-05 15:23 ` Reza Arbab
2017-04-05 15:23 ` Reza Arbab
2017-04-05 6:36 ` Michal Hocko
2017-04-05 6:36 ` Michal Hocko
2017-04-06 13:08 ` Michal Hocko
2017-04-06 13:08 ` Michal Hocko
2017-04-06 15:24 ` Reza Arbab
2017-04-06 15:24 ` Reza Arbab
2017-04-06 15:41 ` Michal Hocko
2017-04-06 15:41 ` Michal Hocko
2017-04-06 15:46 ` Reza Arbab
2017-04-06 15:46 ` Reza Arbab
2017-04-06 16:21 ` Michal Hocko
2017-04-06 16:21 ` Michal Hocko
2017-04-06 16:24 ` Mel Gorman
2017-04-06 16:24 ` Mel Gorman
2017-04-06 16:55 ` Mel Gorman
2017-04-06 16:55 ` Mel Gorman
2017-04-06 17:12 ` Michal Hocko
2017-04-06 17:12 ` Michal Hocko
2017-04-06 17:46 ` Mel Gorman
2017-04-06 17:46 ` Mel Gorman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170404073056.GB15132@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=aarcange@redhat.com \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=arbab@linux.vnet.ibm.com \
--cc=daniel.kiper@oracle.com \
--cc=imammedo@redhat.com \
--cc=js1304@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=qiuxishi@huawei.com \
--cc=rientjes@google.com \
--cc=slaoub@gmail.com \
--cc=tangchen@cn.fujitsu.com \
--cc=toshi.kani@hpe.com \
--cc=vbabka@suse.cz \
--cc=vkuznets@redhat.com \
--cc=yasu.isimatu@gmail.com \
--cc=zhenzhang.zhang@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.