From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750983AbdE2KLg (ORCPT ); Mon, 29 May 2017 06:11:36 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:46820 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750898AbdE2KLf (ORCPT ); Mon, 29 May 2017 06:11:35 -0400 Date: Mon, 29 May 2017 12:11:28 +0200 From: Heiko Carstens To: Michal Hocko Cc: Gerald Schaefer , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [-next] memory hotplug regression References: <20170524082022.GC5427@osiris> <20170524083956.GC14733@dhcp22.suse.cz> <20170526122509.GB14849@osiris> <20170529085231.GE19725@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170529085231.GE19725@dhcp22.suse.cz> User-Agent: Mutt/1.5.24 (2015-08-30) X-TM-AS-GCONF: 00 x-cbid: 17052910-0020-0000-0000-00000377171A X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17052910-0021-0000-0000-000041EAE6C4 Message-Id: <20170529101128.GA12975@osiris> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-05-29_06:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705290192 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 29, 2017 at 10:52:31AM +0200, Michal Hocko wrote: > > Why is it a problem to change the default for 'online'? As far as I can see > > that doesn't have too much to do with the order of zones, no? > > `online' (aka MMOP_ONLINE_KEEP) should always inherit its current zone. > The previous implementation made an exception to allow to shift to > another zone if it is on the border of two zones. This is what I wanted > to get rid of because it is just too ugly to live. > > But now I am not really sure what is the usecase here. I assume you know > how to online the memoery. That's why you had to play tricks with the > zones previously. All you need now is to use the proper MMOP_ONLINE* Yes, however that implies that existing user space has to be changed to achieve the same semantics as before. That's the usecase I'm talking about. On the other hand this change would finally make s390 behave like all other architectures, which is certainly not a bad thing. So, while thinking again I think you convinced me to agree with this change. > > 2) Another oddity is that after a memory block was brought online it's > > association to ZONE_NORMAL or ZONE_MOVABLE seems to be fixed. Even if it > > is brought offline afterwards: > > This is intended behavior because I got rid of the tricky&ugly zone > shifting code. Ultimately I would like to allow for overlapping zones > so the explicit online_{movable,kernel} will _always_ work. Ok, I see. This change (fixed memory block to zone mapping after first online) is a bit surprising. On the other hand I can't think of a sane usecase why one wants to change the zone a memory block belongs to.