Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1169848
| From | "Kirill A. Shutemov" <kirill@shutemov.name> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCHv6 32/36] thp: reintroduce split_huge_page() |
| Date | 2015-06-22 13:30 +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> |
| Organization | linux.* mail to news gateway |
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
Re: [PATCHv6 32/36] thp: reintroduce split_huge_page() "Kirill A. Shutemov" <kirill@shutemov.name> - 2015-06-22 13:30 +0200
csiph-web