linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 00 of 31] Transparent Hugepage support #7
@ 2010-01-26 13:51 Andrea Arcangeli
  2010-01-26 13:51 ` [PATCH 01 of 31] define MADV_HUGEPAGE Andrea Arcangeli
                   ` (31 more replies)
  0 siblings, 32 replies; 118+ messages in thread
From: Andrea Arcangeli @ 2010-01-26 13:51 UTC (permalink / raw)
  To: linux-mm
  Cc: Marcelo Tosatti, Adam Litke, Avi Kivity, Izik Eidus, Hugh Dickins,
	Nick Piggin, Rik van Riel, Mel Gorman, Andi Kleen, Dave Hansen,
	Benjamin Herrenschmidt, Ingo Molnar, Mike Travis,
	KAMEZAWA Hiroyuki, Christoph Lameter, Chris Wright, Andrew Morton,
	bpicco, Christoph Hellwig, KOSAKI Motohiro

Hello,

this is an update that notably fixes one bug in split_huge_page_mm/vma that
was calling find_vma on "address+HPAGE_PMD_SIZE-1" even if address wasn't
always hpage aligned, so it was failing on the last hugepage of the vma unless
"address" was hugepage aligned (firefox flash tripped on this last night, but
thanks to the amount of BUG_ON that I added it was immediate to fix). No more
problems with java applets, flash etc...

This also moves the MADV_HUGEPAGE to 15 to avoid tripping on parisc (this is
just in case, no idea if parisc is planning to support transparent hugepage or
not). Not sure why there's not just one file for all MADV_ defines, there are
4 billions of madv possible with this api so it looks unnecessary to have
per-arch defines.

So this is running fine, no more bugchecks tripping on mprotect and laptop was
rock solid so far.

 14:45:10 up 15:10,  5 users,  load average: 0.22, 0.17, 0.06

 AnonPages:        612988 kB
 AnonHugePages:     65536 kB

--
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 118+ messages in thread
* [PATCH 00 of 31] Transparent Hugepage support #8
@ 2010-01-28 14:33 Andrea Arcangeli
  2010-01-28 14:33 ` [PATCH 24 of 31] kvm mmu transparent hugepage support Andrea Arcangeli
  0 siblings, 1 reply; 118+ messages in thread
From: Andrea Arcangeli @ 2010-01-28 14:33 UTC (permalink / raw)
  To: linux-mm
  Cc: Marcelo Tosatti, Adam Litke, Avi Kivity, Izik Eidus, Hugh Dickins,
	Nick Piggin, Rik van Riel, Mel Gorman, Dave Hansen,
	Benjamin Herrenschmidt, Ingo Molnar, Mike Travis,
	KAMEZAWA Hiroyuki, Christoph Lameter, Chris Wright, Andrew Morton,
	bpicco, Christoph Hellwig, KOSAKI Motohiro, Balbir Singh,
	Arnd Bergmann

Hello,

this is the last covering all review plus fixes for vm_normal_page in
khugepaged (which still results in a warning generated by a pte having
pte_special bit and mapping mmio area in the 256M area of the graphics card of
mst but nor VM_PFNMAP nor VM_MIXEDMAP set, even worse vm_file is null and
vm_ops is null too). I still can't figure out how a special pte can be mapped
in an area with vm_ops and vm_file both null (btw, on a side note I doubt we
ever have a case of vm_ops not null and vm_file null or vm_ops null and
vm_file not null). It happens during the speculative readonly pass and I
intentionally tried to avoid taking the pt lock (it was later taken in
collapse_huge_page of course). I wonder if that's the reason so I added the
pt lock in the speculative pass too, but I can't see how it can happen even
without the lock (the pte can't go away under it because khugepaged holds the
mmap_sem read mode).  I would imagine it could be a problem only if pte
updates weren't atomic as they are on 64bit (despite not being enforced with
asm() constructs but relaying on gcc) so takign pt lock will help on that
side, but even if it was gcc doing partial writes to ptes, it shouldn't be
always pointing to mmio of graphics card.

I can't reproduce the khugepaged warning here, but it's only a warning, it
can't affect stability if it's true my hypotesis that the bug was already
there, and that I only exposed it with khugepaged.

But if it's not my bug, then I wonder why munmap doesn't trip on it too.  The
suspicious code at the moment is i915_gem, things like unmap_mapping_range
etc.. One of my theories is that unmap_mapping_range of i915_gem is not
clearing all ptes and then those pte_special leaks into newly allocated
mappings as new pte are allocated but then I can't imagine this not to have
adverse effects (at the very least it should screwup graphics card at boot
around the time these bugcheck triggers). Also teh bugchecks seem to go away
after 80 sec uptime so maybe the corruption is then cleared as the new
mappings are teardown too (this time correctly through regular munmap and not
->close).

It's my primary focus is to understand that pte_special thing, because other
than the above there is no other known issue so far, and it is rock solid in
all hardware where I deployed it and I leave swapping storms running 24/7 in
addition to khugepaged at 0 scan/defrag_sleep to stress smp safety of
split_huge_page and collapse_huge_page. I rebooted laptop and test server,
only to upgrade the #8 version to include in the testing the new code post
review.

I suggest to try it (especially if you use i915_gem, as I need to know if
anybody else can reproduce the khugepaged warning with pte_special set) and
let me know, the more testing the better.

Thanks,
Andrea

--
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 118+ messages in thread
* [PATCH 00 of 31] Transparent Hugepage support #6
@ 2010-01-25 17:18 Andrea Arcangeli
  2010-01-25 17:19 ` [PATCH 24 of 31] kvm mmu transparent hugepage support Andrea Arcangeli
  0 siblings, 1 reply; 118+ messages in thread
From: Andrea Arcangeli @ 2010-01-25 17:18 UTC (permalink / raw)
  To: linux-mm
  Cc: Marcelo Tosatti, Adam Litke, Avi Kivity, Izik Eidus, Hugh Dickins,
	Nick Piggin, Rik van Riel, Mel Gorman, Andi Kleen, Dave Hansen,
	Benjamin Herrenschmidt, Ingo Molnar, Mike Travis,
	KAMEZAWA Hiroyuki, Christoph Lameter, Chris Wright, Andrew Morton,
	bpicco, Christoph Hellwig, KOSAKI Motohiro

Hello everyone,

so this is working on my laptop and for now on I'll keeping taking advantage
of hugepages here on my laptop (all sysctl set to "always") and there are no
bugs left that I am aware of, my laptop seems rock solid with sound, skype
videocall, youtube etc... On server I'm running this with lockdep, full
preempt and all all debug goodies enabled, and it's doing swap storms of 5G in
a loop with firefox and stuff running as well (which triggers the futex and
stuff on hugepages without splitting them).

The major bug that triggered with firefox was futex (firefox is using
hugepages all the time now), it was tricky to find because futex takes the pin
on a tail page and then run put_page on the head page only, so leaving at a
much later time (during pte teardown) one hugepage being freed but with
bad_page triggering because of the atomic count of the tail page being > 0.

Other cleanups and changes as usual.

I think next submit should be against mmotd, not agaist mainline anymore.
I still wait answer from Dave on the tail page handling for hugetlbfs to
decide if to optimize that bit with yet another new PG_trans_huge bitflag.

--
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 118+ messages in thread

end of thread, other threads:[~2010-01-28 15:58 UTC | newest]

Thread overview: 118+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-01-26 13:51 [PATCH 00 of 31] Transparent Hugepage support #7 Andrea Arcangeli
2010-01-26 13:51 ` [PATCH 01 of 31] define MADV_HUGEPAGE Andrea Arcangeli
2010-01-26 14:49   ` Rik van Riel
2010-01-26 17:49   ` Mel Gorman
2010-01-27 16:37   ` Hugh Dickins
2010-01-27 17:13     ` Andrea Arcangeli
2010-01-27 17:29       ` Hugh Dickins
2010-01-27 17:45     ` Pekka Enberg
2010-01-27 21:44     ` Arnd Bergmann
2010-01-26 13:51 ` [PATCH 02 of 31] compound_lock Andrea Arcangeli
2010-01-26 14:51   ` Rik van Riel
2010-01-26 15:30     ` Andrea Arcangeli
2010-01-26 15:36     ` Christoph Lameter
2010-01-26 15:51       ` Andrea Arcangeli
2010-01-26 17:50   ` Mel Gorman
2010-01-26 13:51 ` [PATCH 03 of 31] alter compound get_page/put_page Andrea Arcangeli
2010-01-26 15:00   ` Rik van Riel
2010-01-26 15:31     ` Andrea Arcangeli
2010-01-26 16:00       ` Christoph Lameter
2010-01-26 18:02   ` Mel Gorman
2010-01-27 18:58     ` Andrea Arcangeli
2010-01-28 15:23       ` Mel Gorman
2010-01-26 13:51 ` [PATCH 04 of 31] update futex compound knowledge Andrea Arcangeli
2010-01-26 16:12   ` Rik van Riel
2010-01-26 17:10     ` Andrea Arcangeli
2010-01-26 19:48       ` Rik van Riel
2010-01-26 18:37   ` Mel Gorman
2010-01-27 19:45     ` Andrea Arcangeli
2010-01-28 15:33       ` Mel Gorman
2010-01-28 15:57         ` Andrea Arcangeli
2010-01-26 13:52 ` [PATCH 05 of 31] fix bad_page to show the real reason the page is bad Andrea Arcangeli
2010-01-26 16:13   ` Rik van Riel
2010-01-26 18:38   ` Mel Gorman
2010-01-26 13:52 ` [PATCH 06 of 31] clear compound mapping Andrea Arcangeli
2010-01-26 16:13   ` Rik van Riel
2010-01-26 18:39   ` Mel Gorman
2010-01-26 13:52 ` [PATCH 07 of 31] add native_set_pmd_at Andrea Arcangeli
2010-01-26 16:14   ` Rik van Riel
2010-01-26 19:10   ` Mel Gorman
2010-01-26 13:52 ` [PATCH 08 of 31] add pmd paravirt ops Andrea Arcangeli
2010-01-26 16:43   ` Rik van Riel
2010-01-26 19:13   ` Mel Gorman
2010-01-26 13:52 ` [PATCH 09 of 31] no paravirt version of pmd ops Andrea Arcangeli
2010-01-26 16:46   ` Rik van Riel
2010-01-26 19:15   ` Mel Gorman
2010-01-26 13:52 ` [PATCH 10 of 31] export maybe_mkwrite Andrea Arcangeli
2010-01-26 16:56   ` Rik van Riel
2010-01-26 19:23   ` Mel Gorman
2010-01-26 13:52 ` [PATCH 11 of 31] comment reminder in destroy_compound_page Andrea Arcangeli
2010-01-26 16:59   ` Rik van Riel
2010-01-26 19:24   ` Mel Gorman
2010-01-26 13:52 ` [PATCH 12 of 31] config_transparent_hugepage Andrea Arcangeli
2010-01-26 17:03   ` Rik van Riel
2010-01-26 19:34   ` Mel Gorman
2010-01-27 19:54     ` Andrea Arcangeli
2010-01-28 15:34       ` Mel Gorman
2010-01-26 13:52 ` [PATCH 13 of 31] add pmd mangling functions to x86 Andrea Arcangeli
2010-01-26 17:11   ` Rik van Riel
2010-01-26 19:41   ` Mel Gorman
2010-01-27 19:59     ` Andrea Arcangeli
2010-01-26 13:52 ` [PATCH 14 of 31] add pmd mangling generic functions Andrea Arcangeli
2010-01-26 17:14   ` Rik van Riel
2010-01-26 19:44   ` Mel Gorman
2010-01-28 15:57     ` Andrea Arcangeli
2010-01-26 13:52 ` [PATCH 15 of 31] special pmd_trans_* functions Andrea Arcangeli
2010-01-26 17:20   ` Rik van Riel
2010-01-26 13:52 ` [PATCH 16 of 31] bail out gup_fast on splitting pmd Andrea Arcangeli
2010-01-26 17:21   ` Rik van Riel
2010-01-26 19:50   ` Mel Gorman
2010-01-26 13:52 ` [PATCH 17 of 31] pte alloc trans splitting Andrea Arcangeli
2010-01-26 17:24   ` Rik van Riel
2010-01-26 19:53   ` Mel Gorman
2010-01-26 13:52 ` [PATCH 18 of 31] add pmd mmu_notifier helpers Andrea Arcangeli
2010-01-26 17:24   ` Rik van Riel
2010-01-26 13:52 ` [PATCH 19 of 31] clear page compound Andrea Arcangeli
2010-01-26 17:25   ` Rik van Riel
2010-01-26 19:56   ` Mel Gorman
2010-01-27 22:51     ` Andrea Arcangeli
2010-01-26 13:52 ` [PATCH 20 of 31] add pmd_huge_pte to mm_struct Andrea Arcangeli
2010-01-26 17:48   ` Rik van Riel
2010-01-26 13:52 ` [PATCH 21 of 31] split_huge_page_mm/vma Andrea Arcangeli
2010-01-26 17:34   ` Mel Gorman
2010-01-26 19:49     ` Andrea Arcangeli
2010-01-26 20:03       ` Mel Gorman
2010-01-26 17:58   ` Rik van Riel
2010-01-26 13:52 ` [PATCH 22 of 31] split_huge_page paging Andrea Arcangeli
2010-01-26 18:02   ` Rik van Riel
2010-01-27 18:43     ` Andrea Arcangeli
2010-01-26 20:08   ` Mel Gorman
2010-01-26 13:52 ` [PATCH 23 of 31] clear_copy_huge_page Andrea Arcangeli
2010-01-26 18:14   ` Rik van Riel
2010-01-26 20:10   ` Mel Gorman
2010-01-26 13:52 ` [PATCH 24 of 31] kvm mmu transparent hugepage support Andrea Arcangeli
2010-01-26 18:16   ` Rik van Riel
2010-01-26 13:52 ` [PATCH 25 of 31] transparent hugepage core Andrea Arcangeli
2010-01-26 22:34   ` Rik van Riel
2010-01-26 13:52 ` [PATCH 26 of 31] madvise(MADV_HUGEPAGE) Andrea Arcangeli
2010-01-26 22:50   ` Rik van Riel
2010-01-26 13:52 ` [PATCH 27 of 31] pmd_trans_huge migrate bugcheck Andrea Arcangeli
2010-01-26 22:51   ` Rik van Riel
2010-01-26 13:52 ` [PATCH 28 of 31] memcg compound Andrea Arcangeli
2010-01-26 22:53   ` Rik van Riel
2010-01-26 13:52 ` [PATCH 29 of 31] memcg huge memory Andrea Arcangeli
2010-01-26 22:53   ` Rik van Riel
2010-01-26 13:52 ` [PATCH 30 of 31] transparent hugepage vmstat Andrea Arcangeli
2010-01-26 22:55   ` Rik van Riel
2010-01-28  1:04     ` Andrea Arcangeli
2010-01-28  1:22       ` Rik van Riel
2010-01-26 13:52 ` [PATCH 31 of 31] khugepaged Andrea Arcangeli
2010-01-26 23:04   ` Rik van Riel
2010-01-26 17:55 ` [PATCH 00 of 31] Transparent Hugepage support #7 Michael S. Tsirkin
2010-01-27  0:00   ` Andrea Arcangeli
2010-01-27  0:32     ` Andrea Arcangeli
2010-01-27  0:47       ` Andrea Arcangeli
2010-01-27 20:20         ` Michael S. Tsirkin
2010-01-27 22:58           ` Andrea Arcangeli
  -- strict thread matches above, loose matches on Subject: below --
2010-01-28 14:33 [PATCH 00 of 31] Transparent Hugepage support #8 Andrea Arcangeli
2010-01-28 14:33 ` [PATCH 24 of 31] kvm mmu transparent hugepage support Andrea Arcangeli
2010-01-25 17:18 [PATCH 00 of 31] Transparent Hugepage support #6 Andrea Arcangeli
2010-01-25 17:19 ` [PATCH 24 of 31] kvm mmu transparent hugepage support Andrea Arcangeli

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).