From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751674AbdG1Fyv (ORCPT ); Fri, 28 Jul 2017 01:54:51 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:41511 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751620AbdG1Fyt (ORCPT ); Fri, 28 Jul 2017 01:54:49 -0400 Subject: Re: [PATCH V3] mm/madvise: Enable (soft|hard) offline of HugeTLB pages at PGD level To: Mike Kravetz , Anshuman Khandual , linux-kernel@vger.kernel.org, linux-mm@kvack.org References: <20170426035731.6924-1-khandual@linux.vnet.ibm.com> <20170516100509.20122-1-khandual@linux.vnet.ibm.com> <04ae16b1-8783-fb3b-4715-b96b6644566f@oracle.com> Cc: akpm@linux-foundation.org From: Anshuman Khandual Date: Fri, 28 Jul 2017 11:23:34 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <04ae16b1-8783-fb3b-4715-b96b6644566f@oracle.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable x-cbid: 17072805-0040-0000-0000-0000034B973E X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17072805-0041-0000-0000-00000CC7F9E6 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-07-28_02:,, 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-1706020000 definitions=main-1707280091 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/28/2017 06:19 AM, Mike Kravetz wrote: > On 05/16/2017 03:05 AM, Anshuman Khandual wrote: >> Though migrating gigantic HugeTLB pages does not sound much like real >> world use case, they can be affected by memory errors. Hence migration >> at the PGD level HugeTLB pages should be supported just to enable soft >> and hard offline use cases. > > Hi Anshuman, > > Sorry for the late question, but I just stumbled on this code when > looking at something else. > > It appears the primary motivation for these changes is to handle > memory errors in gigantic pages. In this case, you migrate to Right. > another gigantic page. However, doesn't this assume that there is Right. > a pre-allocated gigantic page sitting unused that will be the target > of the migration? alloc_huge_page_node will not allocate a gigantic > page. Or, am I missing something? Yes, its in the context of 16GB pages on POWER8 system where all the gigantic pages are pre allocated from the platform and passed on to the kernel through the device tree. We dont allocate these gigantic pages on runtime.