From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ning Qu <quning@google.com>
Subject: Re: [PATCH 07/12] mm, thp, tmpfs: handle huge page in
 shmem_undo_range for truncate
Date: Wed, 16 Oct 2013 11:48:24 -0700
Message-ID: <CACz4_2eAots8Xk3C8Vosqc24vs28OtsD4LecsH19MjWeQaw+2Q@mail.gmail.com>
References: <20131015001304.GH3432@hippobay.mtv.corp.google.com>
 <20131015110146.7E8BEE0090@blue.fi.intel.com> <CACz4_2fiF+vaAbFixgGF+Uxn0av4H8y-aMQdyi3yYs5pdS2WBA@mail.gmail.com>
 <20131016120951.B5012E0090@blue.fi.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: Andrea Arcangeli <aarcange@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Hugh Dickins <hughd@google.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Wu Fengguang <fengguang.wu@intel.com>, Jan Kara <jack@suse.cz>,
	Mel Gorman <mgorman@suse.de>, linux-mm@kvack.org,
	Andi Kleen <ak@linux.intel.com>,
	Matthew Wilcox <willy@linux.intel.com>,
	Hillf Danton <dhillf@gmail.com>, Dave Hansen <dave@sr71.net>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
To: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from mail-vc0-f170.google.com ([209.85.220.170]:36746 "EHLO
	mail-vc0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1759731Ab3JPSsp convert rfc822-to-8bit (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Wed, 16 Oct 2013 14:48:45 -0400
Received: by mail-vc0-f170.google.com with SMTP id lc6so627376vcb.1
        for <linux-fsdevel@vger.kernel.org>; Wed, 16 Oct 2013 11:48:44 -0700 (PDT)
In-Reply-To: <20131016120951.B5012E0090@blue.fi.intel.com>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

Best wishes,
--=20
Ning Qu (=E6=9B=B2=E5=AE=81) | Software Engineer | quning@google.com | =
+1-408-418-6066


On Wed, Oct 16, 2013 at 5:09 AM, Kirill A. Shutemov
<kirill.shutemov@linux.intel.com> wrote:
> Ning Qu wrote:
>> > Again. Here and below ifdef is redundant: PageTransHugeCache() is =
zero
>> > compile-time and  thp case will be optimize out.
>>
>> The problem is actually from HPAGE_CACHE_INDEX_MASK, it is marked as
>> build bug when CONFIG_TRANSPARENT_HUGEPAGE_PAGECACHE is false. So we
>> either wrap some logic inside a inline function, or we have to be li=
ke
>> this .. Or we don't treat the HPAGE_CACHE_INDEX_MASK as a build bug?
>
> HPAGE_CACHE_INDEX_MASK shouldn't be a problem.
> If it's wrapped into 'if PageTransHugeCache(page)' or similar it will=
 be
> eliminated by compiler if thp-pc disabled and build bug will not be
> triggered.
>
Yes, you are totally right about this. I have remove all the ifdef for
CONFIG_TRANSPARENT_HUGEPAGE_PAGECACHE now. Thanks!

>>
>> >
>> > And do we really need a copy of truncate logic here? Is there a wa=
y to
>> > share code?
>> >
>> The truncate between tmpfs and general one is similar but not exactl=
y
>> the same (no readahead), so share the whole function might not be a
>> good choice from the perspective of tmpfs? Anyway, there are other
>> similar functions in tmpfs, e.g. the one you mentioned for
>> shmem_add_to_page_cache. It is possible to share the code, I am just
>> worried it will make the logic more complicated?
>
> I think introducing thp-pc is good opportunity to refactor all these =
code.
>
> --
>  Kirill A. Shutemov
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel=
" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html