Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1169848

Re: [PATCHv6 32/36] thp: reintroduce split_huge_page()

Path csiph.com!aioe.org!bofh.it!news.nic.it!robomod
From "Kirill A. Shutemov" <kirill@shutemov.name>
Newsgroups linux.kernel
Subject Re: [PATCHv6 32/36] thp: reintroduce split_huge_page()
Date Mon, 22 Jun 2015 13:30:02 +0200
Message-ID <pE85k-2e7-13@gated-at.bofh.it> (permalink)
References <pxkkW-7sr-9@gated-at.bofh.it> <pxkuD-7Ey-27@gated-at.bofh.it> <pzQqm-2eT-13@gated-at.bofh.it>
X-Original-To Vlastimil Babka <vbabka@suse.cz>
Razorgate-Kas Rate: 5
Razorgate-Kas {RECEIVED: dynamic ip detected}
Razorgate-Kas Envelope from:
Razorgate-Kas Version: 5.5.3
Razorgate-Kas LuaCore: 215 2015-05-29_17-31-22 60ae4a1b4d01d14f868b20a55aced8d7df7b2e28
Razorgate-Kas Method: none
Razorgate-Kas Lua profiles 78662 [Jun 02 2015]
Razorgate-Kas Status: not_detected
Dkim-Signature v=1; a=rsa-sha256; c=simple/simple; d=shutemov.name; s=default; t=1434972480; bh=rmUbkjxBN7iOJhZR2HZzLxTga18hwXlsRn03N3i86v4=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=biYrg8bfPG33HJECApjWZDdyvnDkd4XJUB5zyI201yWoyqLt6ciwhZI+eeV+10kyK PnfziUUTLyBkxphCPzp0eT/KfQzJeiAdfw7NQfAva49aZ72JDeO63BY4liPg7HzuP5 15DnMGIo1CEMRocCLl7K9XXeuMob0tYjCYw+ASXQ=
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Disposition inline
User-Agent Mutt/1.5.23.1 (2014-03-12)
Sender robomod@news.nic.it
List-ID <linux-kernel.vger.kernel.org>
X-Mailing-List linux-kernel@vger.kernel.org
Approved robomod@news.nic.it
Lines 51
Organization linux.* mail to news gateway
X-Original-Cc "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>, Andrew Morton <akpm@linux-foundation.org>, Andrea Arcangeli <aarcange@redhat.com>, Hugh Dickins <hughd@google.com>, Dave Hansen <dave.hansen@intel.com>, Mel Gorman <mgorman@suse.de>, Rik van Riel <riel@redhat.com>, Christoph Lameter <cl@gentwo.org>, Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>, Steve Capper <steve.capper@linaro.org>, "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>, Johannes Weiner <hannes@cmpxchg.org>, Michal Hocko <mhocko@suse.cz>, Jerome Marchand <jmarchan@redhat.com>, Sasha Levin <sasha.levin@oracle.com>, linux-kernel@vger.kernel.org, linux-mm@kvack.org
X-Original-Date Mon, 22 Jun 2015 14:28:00 +0300
X-Original-Message-ID <20150622112800.GD7934@node.dhcp.inet.fi>
X-Original-References <1433351167-125878-1-git-send-email-kirill.shutemov@linux.intel.com> <1433351167-125878-33-git-send-email-kirill.shutemov@linux.intel.com> <55785B5E.3000306@suse.cz>
X-Original-Sender linux-kernel-owner@vger.kernel.org
Xref aioe.org linux.kernel:1169848

Show key headers only | View raw


On Wed, Jun 10, 2015 at 05:44:30PM +0200, Vlastimil Babka wrote:
> On 06/03/2015 07:06 PM, Kirill A. Shutemov wrote:
> >+static int __split_huge_page_tail(struct page *head, int tail,
> >+		struct lruvec *lruvec, struct list_head *list)
> >+{
> >+	int mapcount;
> >+	struct page *page_tail = head + tail;
> >+
> >+	mapcount = page_mapcount(page_tail);
> 
> Isn't page_mapcount() unnecessarily heavyweight here? When you are splitting
> a page, it already should have zero compound_mapcount() and shouldn't be
> PageDoubleMap(), no? So you should care about page->_mapcount only? Sure,
> splitting THP is not a hotpath, but when done 512 times per split, it could
> make some difference in the split's latency.

Okay, replaced with direct atomic_read().

> >+	VM_BUG_ON_PAGE(atomic_read(&page_tail->_count) != 0, page_tail);
> >+
> >+	/*
> >+	 * tail_page->_count is zero and not changing from under us. But
> >+	 * get_page_unless_zero() may be running from under us on the
> >+	 * tail_page. If we used atomic_set() below instead of atomic_add(), we
> >+	 * would then run atomic_set() concurrently with
> >+	 * get_page_unless_zero(), and atomic_set() is implemented in C not
> >+	 * using locked ops. spin_unlock on x86 sometime uses locked ops
> >+	 * because of PPro errata 66, 92, so unless somebody can guarantee
> >+	 * atomic_set() here would be safe on all archs (and not only on x86),
> >+	 * it's safer to use atomic_add().
> 
> I would be surprised if this was the first place to use atomic_set() with
> potential concurrent atomic_add(). Shouldn't atomic_*() API guarantee that
> this works?

I don't have much insight on the issue. This part is carried over from
pre-rework split_huge_page().

> 
> >+	 */
> >+	atomic_add(page_mapcount(page_tail) + 1, &page_tail->_count);
> 
> You already have the value in mapcount variable, so why read it again.

Fixed.

-- 
 Kirill A. Shutemov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | Next | Find similar | Unroll thread


Thread

Re: [PATCHv6 32/36] thp: reintroduce split_huge_page() "Kirill A. Shutemov" <kirill@shutemov.name> - 2015-06-22 13:30 +0200

csiph-web