On Tue, Nov 5, 2013 at 2:10 PM, Andrea Arcangeli <aarcange@xxxxxxxxxx> wrote: > Hi, > > this patch is an alternative implementation of the hugetlbfs directio > optimization discussed earlier. We've been looking into this with > Khalid last week and an earlier version of this patch (fully > equivalent as far as CPU overhead is concerned) was benchmarked by > Khalid and it didn't degrade performance compared to the PageHuge > check in current upstream code, so we should be good. > > The patch applies cleanly only after reverting > 7cb2ef56e6a8b7b368b2e883a0a47d02fed66911, it's much easier to review > it in this form as it avoids all the alignment changes. I'll resend to > Andrew against current upstream by squashing it with the revert after > reviews. > > I wished to remove the _mapcount tailpage refcounting for slab and > hugetlbfs tails too, but if the last put_page of a slab tail happens > after the slab page isn't a slab page anymore (but still compound as > it wasn't freed yet because of the tail pin), a VM_BUG_ON would > trigger during the last (unpinning) put_page(slab_tail) with the > mapcount underflow: > > VM_BUG_ON(page_mapcount(page) <= 0); > > Not even sure if any driver is doing anything like that, but the > current code would allow it, Pravin should know more about when > exactly in which conditions the last put_page is done on slab tail > pages. > Yes, This can happen when slab object is directly passed for IO and it is done in few filesystems (ocfs, xfs) when I checked last time. > It shall be possible to remove the _mapcount refcounting anyway, as it > is only read by split_huge_page and so it doesn't actually matter if > it underflows, but I prefer to keep the VM_BUG_ON. In fact I added one > more VM_BUG_ON(!PageHead()) even in this patch. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>