Date: Wed, 28 Sep 2022 19:34:57 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Maxim Sobolev <sobomax@freebsd.org>, Alan Somers <asomers@freebsd.org> Cc: src-committers <src-committers@freebsd.org>, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: d3f96f661050 - main - Fix O(n^2) behavior in sysctl Message-ID: <008896fa-9b89-3114-f2a5-99dc9da5f600@FreeBSD.org> In-Reply-To: <CAH7qZfvgRyva8gry0J1VX2oUGcJ8ncPsavkjHa9GdYYiSu_-DQ@mail.gmail.com> References: <202209270004.28R04K1r086731@gitrepo.freebsd.org> <CAH7qZfvgRyva8gry0J1VX2oUGcJ8ncPsavkjHa9GdYYiSu_-DQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 28/09/2022 19:18, Maxim Sobolev wrote: > This also brings a question as to whether sysctl is the right interface to pull > this data from the kernel in the first place? From my somewhat ignorant look > this approach is likely to be poised with all sorts of race conditions, such so > if configuration changes while you are pulling it out you'd get some > inconsistent view that is not here not there. Wouldn't it be easier to use some > other mechanism to pull configuration of all 1,000 datasets as one blob in one > or few system calls? Like read(2) from /dev/zfsstats or something like that? > Then you can iterate over it as much as you need in userland. I've learnt that we do not talk about the "sensors framework" in a good company, but one of the reasons it got killed was the "inadequate" sysctl mechanism for querying [allegedly massive amounts of] data. > On Tue, Sep 27, 2022, 3:04 AM Alan Somers <asomers@freebsd.org > <mailto:asomers@freebsd.org>> wrote: > > The branch main has been updated by asomers: > > URL: > https://cgit.FreeBSD.org/src/commit/?id=d3f96f661050e9bd21fe29931992a8b9e67ff189 <https://cgit.FreeBSD.org/src/commit/?id=d3f96f661050e9bd21fe29931992a8b9e67ff189>; > > commit d3f96f661050e9bd21fe29931992a8b9e67ff189 > Author: Alan Somers <asomers@FreeBSD.org> > AuthorDate: 2022-09-07 14:12:49 +0000 > Commit: Alan Somers <asomers@FreeBSD.org> > CommitDate: 2022-09-27 00:03:34 +0000 > > Fix O(n^2) behavior in sysctl > > Sysctl OIDs were internally stored in linked lists, triggering O(n^2) > behavior when userland iterates over many of them. The slowdown is > noticeable for MIBs that have > 100 children (for example, vm.uma). But > it's unignorable for kstat.zfs when a pool has > 1000 datasets. > > Convert the linked lists into RB trees. This produces a ~25x speedup > for listing kstat.zfs with 4100 datasets, and no measurable penalty for > small dataset counts. > > Bump __FreeBSD_version for the KPI change. > > Sponsored by: Axcient > Reviewed by: mjg > Differential Revision: https://reviews.freebsd.org/D36500 > <https://reviews.freebsd.org/D36500>; \ -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?008896fa-9b89-3114-f2a5-99dc9da5f600>