From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Kirill A. Shutemov" Subject: Re: [PATCH 07/12] mm, thp, tmpfs: handle huge page in shmem_undo_range for truncate Date: Wed, 16 Oct 2013 15:09:51 +0300 (EEST) Message-ID: <20131016120951.B5012E0090@blue.fi.intel.com> References: <20131015001304.GH3432@hippobay.mtv.corp.google.com> <20131015110146.7E8BEE0090@blue.fi.intel.com> Content-Transfer-Encoding: 7bit Cc: "Kirill A. Shutemov" , Andrea Arcangeli , Andrew Morton , Hugh Dickins , Al Viro , Wu Fengguang , Jan Kara , Mel Gorman , linux-mm@kvack.org, Andi Kleen , Matthew Wilcox , Hillf Danton , Dave Hansen , Alexander Shishkin , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org To: Ning Qu Return-path: In-Reply-To: Sender: owner-linux-mm@kvack.org List-Id: linux-fsdevel.vger.kernel.org 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 like > 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. > > > > > And do we really need a copy of truncate logic here? Is there a way to > > share code? > > > The truncate between tmpfs and general one is similar but not exactly > 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, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org