From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751624AbdJVQCs (ORCPT ); Sun, 22 Oct 2017 12:02:48 -0400 Received: from mga11.intel.com ([192.55.52.93]:63201 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751322AbdJVQCq (ORCPT ); Sun, 22 Oct 2017 12:02:46 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.43,418,1503385200"; d="asc'?scan'208";a="165631705" Date: Sun, 22 Oct 2017 23:55:51 +0800 From: "Du, Changbin" To: Christopher Lameter Cc: Changbin Du , akpm@linux-foundation.org, corbet@lwn.net, hughd@google.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, khandual@linux.vnet.ibm.com, kirill@shutemov.name Subject: Re: [PATCH v2 1/2] mm, thp: introduce dedicated transparent huge page allocation interfaces Message-ID: <20171022155551.GA23682@intel.com> References: <1508488588-23539-1-git-send-email-changbin.du@intel.com> <1508488588-23539-2-git-send-email-changbin.du@intel.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XsQoSWH+UP9D9v3l" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Lameter, On Fri, Oct 20, 2017 at 06:35:44AM -0500, Christopher Lameter wrote: > On Fri, 20 Oct 2017, changbin.du@intel.com wrote: >=20 > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > > index 269b5df..2a960fc 100644 > > --- a/mm/huge_memory.c > > +++ b/mm/huge_memory.c > > @@ -501,6 +501,43 @@ void prep_transhuge_page(struct page *page) > > set_compound_page_dtor(page, TRANSHUGE_PAGE_DTOR); > > } > > > > +struct page *alloc_transhuge_page_vma(gfp_t gfp_mask, > > + struct vm_area_struct *vma, unsigned long addr) > > +{ > > + struct page *page; > > + > > + page =3D alloc_pages_vma(gfp_mask | __GFP_COMP, HPAGE_PMD_ORDER, > > + vma, addr, numa_node_id(), true); > > + if (unlikely(!page)) > > + return NULL; > > + prep_transhuge_page(page); > > + return page; > > +} > > + > > +struct page *alloc_transhuge_page_nodemask(gfp_t gfp_mask, > > + int preferred_nid, nodemask_t *nmask) > > +{ > > + struct page *page; > > + > > + page =3D __alloc_pages_nodemask(gfp_mask | __GFP_COMP, HPAGE_PMD_ORDE= R, > > + preferred_nid, nmask); > > + if (unlikely(!page)) > > + return NULL; > > + prep_transhuge_page(page); > > + return page; > > +} > > + > > +struct page *alloc_transhuge_page(gfp_t gfp_mask) > > +{ > > + struct page *page; > > + > > + page =3D alloc_pages(gfp_mask | __GFP_COMP, HPAGE_PMD_ORDER); > > + if (unlikely(!page)) > > + return NULL; > > + prep_transhuge_page(page); > > + return page; > > +} > > + >=20 > These look pretty similar to the code used for huge pages (aside from the > call to prep_transhuge_page(). Maybe we can have common allocation > primitives for huge pages? >=20 yes, they are similar to each other, but allocation approaches are much dif= ferent. hugetlbfs alloc page from reserved memory, while thp just directly get page =66rom page allocator. I think it doesn't make much sense to provide uified api for both of them, = because transhuge_page allocation primitives only used within hugetlbfs code. thp allocation is more common as system wide. If Unify them then all the api ne= ed 1 more parameter to distinguish what huge page is going to allocate. --=20 Thanks, Changbin Du --XsQoSWH+UP9D9v3l Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJZ7L+HAAoJEAanuZwLnPNUazgIALdl2JgCnklCaTit1zZWHe5o vRr5E1fklq4Jjmu2YEg95mwpSnzN9JvF61JIRhx/vUtA1fBNpr4Tw5vYxLXIb3vB CNystPbnhZ8fupu76T805TteEMgJ+iZeHi93Qo1Nn8LQko+zVmLNYAtH/IalR07S awNlccuTqpeM7B8OaRyWelV//7g8xC0/1cxmM3qUGHrTrz0e+yecug59G3JBhc+q TOx1k9gF4h/3PLBND20RC6ymw9a7SE7/YZzzw66fvyQpc7nkhVBHPyIjZh4IvyQZ r4s8C4KldrCR3A7zwW0QcrBNBjFNU45CyLUD9cT4TRCGghJ9xWXWnz0tla7oJwk= =pLeN -----END PGP SIGNATURE----- --XsQoSWH+UP9D9v3l--