From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933179AbdDSGnQ (ORCPT ); Wed, 19 Apr 2017 02:43:16 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:58950 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760246AbdDSGnO (ORCPT ); Wed, 19 Apr 2017 02:43:14 -0400 Subject: Re: [RFC] mm/madvise: Enable (soft|hard) offline of HugeTLB pages at PGD level To: "Aneesh Kumar K.V" , Anshuman Khandual , linux-kernel@vger.kernel.org, linux-mm@kvack.org References: <20170419032759.29700-1-khandual@linux.vnet.ibm.com> <877f2ghqaf.fsf@skywalker.in.ibm.com> Cc: n-horiguchi@ah.jp.nec.com, akpm@linux-foundation.org From: Anshuman Khandual Date: Wed, 19 Apr 2017 12:12:17 +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: <877f2ghqaf.fsf@skywalker.in.ibm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable x-cbid: 17041906-0016-0000-0000-0000022F487F X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17041906-0017-0000-0000-000006AA45F0 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-04-19_04:,, 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-1704190062 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/19/2017 11:50 AM, Aneesh Kumar K.V wrote: > Anshuman Khandual writes: > >> 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. > > In that case do we want to isolated the entire 16GB range ? Should we > just dequeue the page from hugepage pool convert them to regular 64K > pages and then isolate the 64K that had memory error ? Though its a better thing to do, assuming that we can actually dequeue the huge page and push it to the buddy allocator as normal 64K pages (need to check on this as the original allocation happened from the memblock instead of the buddy allocator, guess it should be possible given that we do similar stuff during memory hot plug). In that case we will also have to consider the same for the PMD based HugeTLB pages as well or it should be only for these gigantic huge pages ?