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 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).