Date: Wed, 21 Feb 2018 09:02:57 -0800 From: Conrad Meyer <cem@freebsd.org> To: Andrew Turner <andrew@fubar.geek.nz> Cc: src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r329612 - in head/sys: kern sys Message-ID: <CAG6CVpXWpVUSaXwKni8hQCVAPCsPtpFfvjfYHHXbWgYKji1hig@mail.gmail.com> In-Reply-To: <F9823809-BB07-4C75-BF77-B6F3833B0687@fubar.geek.nz> References: <201802200006.w1K067ZL032311@repo.freebsd.org> <F9823809-BB07-4C75-BF77-B6F3833B0687@fubar.geek.nz>
index | next in thread | previous in thread | raw e-mail
Do you have r329672 yet? Best, Conrad On Wed, Feb 21, 2018 at 7:11 AM, Andrew Turner <andrew@fubar.geek.nz> wrote: > >> On 20 Feb 2018, at 00:06, Jeff Roberson <jeff@FreeBSD.org> wrote: >> >> Author: jeff >> Date: Tue Feb 20 00:06:07 2018 >> New Revision: 329612 >> URL: https://svnweb.freebsd.org/changeset/base/329612 >> >> Log: >> Further parallelize the buffer cache. >> >> Provide multiple clean queues partitioned into 'domains'. Each domain manages >> its own bufspace and has its own bufspace daemon. Each domain has a set of >> subqueues indexed by the current cpuid to reduce lock contention on the cleanq. >> >> Refine the sleep/wakeup around the bufspace daemon to use atomics as much as >> possible. >> >> Add a B_REUSE flag that is used to requeue bufs during the scan to approximate >> LRU rather than locking the queue on every use of a frequently accessed buf. >> >> Implement bufspace_reserve with only atomic_fetchadd to avoid loop restarts. >> >> Reviewed by: markj >> Tested by: pho >> Sponsored by: Netflix, Dell/EMC Isilon >> Differential Revision: https://reviews.freebsd.org/D14274 > > I’m seeing the following panic on FreeBSD/arm64 after this change. > > Andrew > > panic: bq_remove: Remove buffer 0xffff00004082f260 from wrong queue. > cpuid = 4 > time = 1519088201 > KDB: stack backtrace: > db_trace_self() at db_trace_self_wrapper+0x28 > pc = 0xffff00000062fee4 lr = 0xffff0000000c0450 > sp = 0xffff000040364480 fp = 0xffff000040364690 > > db_trace_self_wrapper() at vpanic+0x184 > pc = 0xffff0000000c0450 lr = 0xffff000000354ce8 > sp = 0xffff0000403646a0 fp = 0xffff000040364720 > > vpanic() at kassert_panic+0x158 > pc = 0xffff000000354ce8 lr = 0xffff000000354b60 > sp = 0xffff000040364730 fp = 0xffff0000403647f0 > > kassert_panic() at bq_remove+0x178 > pc = 0xffff000000354b60 lr = 0xffff0000003f7014 > sp = 0xffff000040364800 fp = 0xffff000040364810 > > bq_remove() at buf_recycle+0x100 > pc = 0xffff0000003f7014 lr = 0xffff0000003fca80 > sp = 0xffff000040364820 fp = 0xffff000040364880 > > buf_recycle() at bufspace_daemon+0xb4 > pc = 0xffff0000003fca80 lr = 0xffff0000003fd31c > sp = 0xffff000040364890 fp = 0xffff000040364910 > > bufspace_daemon() at fork_exit+0x7c > pc = 0xffff0000003fd31c lr = 0xffff000000318388 > sp = 0xffff000040364920 fp = 0xffff000040364950 > > fork_exit() at fork_trampoline+0x10 > pc = 0xffff000000318388 lr = 0xffff000000649ec4 > sp = 0xffff000040364960 fp = 0x0000000000000000 > > KDB: enter: panichelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAG6CVpXWpVUSaXwKni8hQCVAPCsPtpFfvjfYHHXbWgYKji1hig>