> Transparent huge pages are not helpful for DB workload which there is a lot
> of
> shared memory
Hmm. Perhaps they should be. If a database allocates most[1] of the memory on a
machine to a shared memory segment - that *ought* to be a candidate for using
transparent huge pages. Now that we h
>>Sorry, I have no meaningful progress on this. Splitting hugepages is not
>>a trivial operation, and introduce more complexity on hugetlbfs code.
>>I don't hit on any usecase of it rather than memory failure, so I'm not
>>sure that it's worth doing now.
>
> Agreed. ;-)
Agreed that huge pages shou
On Mon, Sep 16, 2013 at 09:50:06PM +, Luck, Tony wrote:
> This is good - but the real solution is to stop poisoning entire huge pages
> ... they should
> be broken into 4K pages and just one 4K page should be poisoned.
>
> Naoya Horiguchi: I thought that you were looking at this problem some
This is good - but the real solution is to stop poisoning entire huge pages ...
they should
be broken into 4K pages and just one 4K page should be poisoned.
Naoya Horiguchi: I thought that you were looking at this problem some months
ago. Any progress?
-Tony
--
To unsubscribe from this list: se
> Reviewed-by: Naoya Horiguchi
> Signed-off-by: Wanpeng Li
Acked-by: Andi Kleen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
madvise_hwpoison won't check if the page is small page or huge page and
traverse
in small page granularity against the range unconditional, which result in a
printk
flood "MCE xxx: already hardware poisoned" if the page is huge page. This patch
fix
it by increase compound_order(compound_head(
6 matches
Mail list logo
