From: Sergey Senozhatsky <senozhatsky@chromium.org>
To: Mike Kravetz <mike.kravetz@oracle.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Muchun Song <songmuchun@bytedance.com>,
Joao Martins <joao.m.martins@oracle.com>,
Konrad Dybcio <konradybcio@kernel.org>,
Oscar Salvador <osalvador@suse.de>,
David Hildenbrand <david@redhat.com>,
Miaohe Lin <linmiaohe@huawei.com>,
David Rientjes <rientjes@google.com>,
Anshuman Khandual <anshuman.khandual@arm.com>,
Naoya Horiguchi <naoya.horiguchi@linux.dev>,
Barry Song <21cnbao@gmail.com>, Michal Hocko <mhocko@suse.com>,
Matthew Wilcox <willy@infradead.org>,
Xiongchun Duan <duanxiongchun@bytedance.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Bisected: [PATCH v7 2/8] hugetlb: restructure pool allocations
Date: Wed, 11 Oct 2023 15:47:56 +0900 [thread overview]
Message-ID: <20231011064756.GB2866435@google.com> (raw)
In-Reply-To: <20231006032012.296473-3-mike.kravetz@oracle.com>
On (23/10/05 20:20), Mike Kravetz wrote:
> Allocation of a hugetlb page for the hugetlb pool is done by the routine
> alloc_pool_huge_page. This routine will allocate contiguous pages from
> a low level allocator, prep the pages for usage as a hugetlb page and
> then add the resulting hugetlb page to the pool.
>
> In the 'prep' stage, optional vmemmap optimization is done. For
> performance reasons we want to perform vmemmap optimization on multiple
> hugetlb pages at once. To do this, restructure the hugetlb pool
> allocation code such that vmemmap optimization can be isolated and later
> batched.
>
> The code to allocate hugetlb pages from bootmem was also modified to
> allow batching.
>
> No functional changes, only code restructure.
I'm afraid there are some functional changes.
[...]
# good: [9e6c86c616f7d4b166c12f1ea9b69831f85c4a86] hugetlb: optimize update_and_free_pages_bulk to avoid lock cycles
git bisect good 9e6c86c616f7d4b166c12f1ea9b69831f85c4a86
# bad: [1d50db09471e2a67272cee6e004ffed380ac571b] Merge branch 'master' of git://linuxtv.org/mchehab/media-next.git
git bisect bad 1d50db09471e2a67272cee6e004ffed380ac571b
# good: [80b14e865ea20ddc20aae61e2c106ebb03257cd3] bcachefs: Lower BCH_NAME_MAX to 512
git bisect good 80b14e865ea20ddc20aae61e2c106ebb03257cd3
# bad: [31d068de8a0de2c44168bbd8a62da21a7bc76051] Merge branch 'for-linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git
git bisect bad 31d068de8a0de2c44168bbd8a62da21a7bc76051
# bad: [0bb194b29fa6296a74b989e0f7f2db4fc11d8012] Merge branch 'perf-tools-next' of git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git
git bisect bad 0bb194b29fa6296a74b989e0f7f2db4fc11d8012
# good: [62001c9bf6aad59dc800c16613e5440b9226c252] Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/wpan/wpan.git
git bisect good 62001c9bf6aad59dc800c16613e5440b9226c252
# good: [21d856352ab78daffb9d05296b87b570f3afac33] Merge branch 'mm-stable' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
git bisect good 21d856352ab78daffb9d05296b87b570f3afac33
# good: [7fded33c6971b6c8e87cbbf48e74536aacca2991] perf test: Add pmu-event test for "Compat" and new event_field.
git bisect good 7fded33c6971b6c8e87cbbf48e74536aacca2991
# good: [4c37b665186a5e2907bf0308474ac3f15eb847da] compiler.h: move __is_constexpr() to compiler.h
git bisect good 4c37b665186a5e2907bf0308474ac3f15eb847da
# bad: [3424f8f382bd4d30e01eaf316823321ef7bd1560] mm: delete checks for xor_unlock_is_negative_byte()
git bisect bad 3424f8f382bd4d30e01eaf316823321ef7bd1560
# bad: [b5c6a60fe5b0339ba9c54f9f871db5c4a0e47906] iomap: protect read_bytes_pending with the state_lock
git bisect bad b5c6a60fe5b0339ba9c54f9f871db5c4a0e47906
# bad: [bfae92330ddc44968c628c0085082d25061495a4] hugetlb: batch PMD split for bulk vmemmap dedup
git bisect bad bfae92330ddc44968c628c0085082d25061495a4
# bad: [fb59f2cb8956f3888d2e0b438cc503565aa3c405] hugetlb: perform vmemmap optimization on a list of pages
git bisect bad fb59f2cb8956f3888d2e0b438cc503565aa3c405
# bad: [bfb41d6b2fe148c939366957ea9cb9aa72d59c4c] hugetlb: restructure pool allocations
git bisect bad bfb41d6b2fe148c939366957ea9cb9aa72d59c4c
# first bad commit: [bfb41d6b2fe148c939366957ea9cb9aa72d59c4c] hugetlb: restructure pool allocations
bfb41d6b2fe148c939366957ea9cb9aa72d59c4c is the first bad commit
commit bfb41d6b2fe148c939366957ea9cb9aa72d59c4c
Author: Mike Kravetz
Date: Thu Oct 5 20:20:04 2023 -0700
hugetlb: restructure pool allocations
Bugs-on linux-next:
[ 0.827640] ------------[ cut here ]------------
[ 0.828608] kernel BUG at mm/hugetlb.c:3180!
[ 0.829812] invalid opcode: 0000 [#1] PREEMPT SMP PTI
[ 0.830610] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.6.0-rc4+ #164
[ 0.830610] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
[ 0.830610] RIP: 0010:gather_bootmem_prealloc+0x1c5/0x1d0
[ 0.830610] Code: 48 89 e6 4c 89 ff e8 aa 13 83 fe 65 48 8b 04 25 28 00 00 00 48 3b 44 24 10 75 11 48 83 c4 18 5b 41 5c 41 5d 41 5e 41 5f 5d c3 <0f> 0b e8 64 f9 04 ff 0f 1f 40 00 0f 1f 44 00 00 55 48 89 e5 41 57
[ 0.830610] RSP: 0000:ffffc90000017b00 EFLAGS: 00010297
[ 0.830610] RAX: ffffc90000017b00 RBX: ffffea0000000000 RCX: ffffffff83847358
[ 0.830610] RDX: ffffffff83847358 RSI: fffffffffffffec8 RDI: 0000000000000000
[ 0.830610] RBP: 0000000000000000 R08: ffff8881030bc708 R09: ffff8881030bc710
[ 0.830610] R10: 0000000000000001 R11: 000077791a770248 R12: ffffffff82224228
[ 0.830610] R13: 0000000000000001 R14: ffffffff82ae6630 R15: ffffffff83847220
[ 0.830610] FS: 0000000000000000(0000) GS:ffff888661e00000(0000) knlGS:0000000000000000
[ 0.830610] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 0.830610] CR2: ffff88867ffff000 CR3: 0000000002246001 CR4: 0000000000770ef0
[ 0.830610] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 0.830610] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 0.830610] PKRU: 55555554
[ 0.830610] Call Trace:
[ 0.830610] <TASK>
[ 0.830610] ? __die_body+0x67/0xb0
[ 0.830610] ? die+0xa0/0xc0
[ 0.830610] ? do_trap+0xa8/0x180
[ 0.830610] ? gather_bootmem_prealloc+0x1c5/0x1d0
[ 0.830610] ? do_error_trap+0xc6/0x110
[ 0.830610] ? gather_bootmem_prealloc+0x1c5/0x1d0
[ 0.830610] ? handle_invalid_op+0x25/0x30
[ 0.830610] ? gather_bootmem_prealloc+0x1c5/0x1d0
[ 0.830610] ? exc_invalid_op+0x2f/0x40
[ 0.830610] ? asm_exc_invalid_op+0x16/0x20
[ 0.830610] ? gather_bootmem_prealloc+0x1c5/0x1d0
[ 0.830610] ? __alloc_bootmem_huge_page+0x120/0x120
[ 0.830610] hugetlb_init+0x14a/0x280
[ 0.830610] ? _raw_spin_unlock_irqrestore+0x3d/0x60
[ 0.830610] ? __alloc_bootmem_huge_page+0x120/0x120
[ 0.830610] do_one_initcall+0xce/0x2d0
[ 0.830610] ? __lock_acquire+0x5db/0x2d40
[ 0.830610] ? ida_alloc_range+0xaf/0x3e0
[ 0.830610] ? proc_register+0x4e/0x1b0
[ 0.830610] ? __kmem_cache_alloc_node+0x2f/0x200
[ 0.830610] ? lock_is_held_type+0xdd/0x150
[ 0.830610] ? do_initcalls+0x1c/0x70
[ 0.830610] ? parse_args+0x16f/0x340
[ 0.830610] do_initcall_level+0xab/0x110
[ 0.830610] ? kernel_init+0x16/0x190
[ 0.830610] do_initcalls+0x3f/0x70
[ 0.830610] kernel_init_freeable+0x15c/0x1d0
[ 0.830610] ? rest_init+0x1f0/0x1f0
[ 0.830610] kernel_init+0x16/0x190
[ 0.830610] ret_from_fork+0x2f/0x40
[ 0.830610] ? rest_init+0x1f0/0x1f0
[ 0.830610] ret_from_fork_asm+0x11/0x20
[ 0.830610] </TASK>
[ 0.830610] Modules linked in:
[ 0.830614] ---[ end trace 0000000000000000 ]---
[ 0.831896] RIP: 0010:gather_bootmem_prealloc+0x1c5/0x1d0
[ 0.833386] Code: 48 89 e6 4c 89 ff e8 aa 13 83 fe 65 48 8b 04 25 28 00 00 00 48 3b 44 24 10 75 11 48 83 c4 18 5b 41 5c 41 5d 41 5e 41 5f 5d c3 <0f> 0b e8 64 f9 04 ff 0f 1f 40 00 0f 1f 44 00 00 55 48 89 e5 41 57
[ 0.833947] RSP: 0000:ffffc90000017b00 EFLAGS: 00010297
[ 0.835384] RAX: ffffc90000017b00 RBX: ffffea0000000000 RCX: ffffffff83847358
[ 0.837279] RDX: ffffffff83847358 RSI: fffffffffffffec8 RDI: 0000000000000000
[ 0.839237] RBP: 0000000000000000 R08: ffff8881030bc708 R09: ffff8881030bc710
[ 0.840613] R10: 0000000000000001 R11: 000077791a770248 R12: ffffffff82224228
[ 0.842567] R13: 0000000000000001 R14: ffffffff82ae6630 R15: ffffffff83847220
[ 0.843946] FS: 0000000000000000(0000) GS:ffff888661e00000(0000) knlGS:0000000000000000
[ 0.846170] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 0.847279] CR2: ffff88867ffff000 CR3: 0000000002246001 CR4: 0000000000770ef0
[ 0.849242] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 0.850613] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 0.852581] PKRU: 55555554
[ 0.853336] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[ 0.853944] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
next prev parent reply other threads:[~2023-10-11 6:48 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-06 3:20 [PATCH v7 0/8] Batch hugetlb vmemmap modification operations Mike Kravetz
2023-10-06 3:20 ` [PATCH v7 1/8] hugetlb: optimize update_and_free_pages_bulk to avoid lock cycles Mike Kravetz
2023-10-06 3:20 ` [PATCH v7 2/8] hugetlb: restructure pool allocations Mike Kravetz
2023-10-11 6:47 ` Sergey Senozhatsky [this message]
2023-10-18 22:44 ` Bisected: " Mike Kravetz
2023-10-19 2:15 ` Sergey Senozhatsky
2023-10-19 2:29 ` Mike Kravetz
2023-10-06 3:20 ` [PATCH v7 3/8] hugetlb: perform vmemmap optimization on a list of pages Mike Kravetz
2023-10-06 3:20 ` [PATCH v7 4/8] hugetlb: perform vmemmap restoration " Mike Kravetz
2023-10-06 3:20 ` [PATCH v7 5/8] hugetlb: batch freeing of vmemmap pages Mike Kravetz
2023-10-06 3:20 ` [PATCH v7 6/8] hugetlb: batch PMD split for bulk vmemmap dedup Mike Kravetz
2023-10-06 3:20 ` [PATCH v7 7/8] hugetlb: batch TLB flushes when freeing vmemmap Mike Kravetz
2023-10-06 3:20 ` [PATCH v7 8/8] hugetlb: batch TLB flushes when restoring vmemmap Mike Kravetz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231011064756.GB2866435@google.com \
--to=senozhatsky@chromium.org \
--cc=21cnbao@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=anshuman.khandual@arm.com \
--cc=david@redhat.com \
--cc=duanxiongchun@bytedance.com \
--cc=joao.m.martins@oracle.com \
--cc=konradybcio@kernel.org \
--cc=linmiaohe@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=mike.kravetz@oracle.com \
--cc=naoya.horiguchi@linux.dev \
--cc=osalvador@suse.de \
--cc=rientjes@google.com \
--cc=songmuchun@bytedance.com \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.