Date: Fri, 1 Aug 2014 21:59:06 -0600 From: "Justin T. Gibbs" <gibbs@scsiguy.com> To: Xin LI <delphij@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r269404 - head/sys/cddl/compat/opensolaris/sys Message-ID: <57D656EF-5D6B-428B-9DCE-7FA360B1407F@scsiguy.com> In-Reply-To: <201408012233.s71MXNIx051919@svn.freebsd.org> References: <201408012233.s71MXNIx051919@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Aug 1, 2014, at 4:33 PM, Xin LI <delphij@freebsd.org> wrote: > Author: delphij > Date: Fri Aug 1 22:33:23 2014 > New Revision: 269404 > URL: http://svnweb.freebsd.org/changeset/base/269404 >=20 > Log: > Split gethrtime() and gethrtime_waitfree() and make the former use > nanouptime() instead of getnanouptime(). nanouptime(9) provides more > precise result at expense of being slower. >=20 > In r269223, gethrtime() is used as creation time of dbuf, which in = turn > acts as portion of lookup key to maintain AVL invariant where there = can > not be duplicate items. Before this change, gethrtime() have = preferred > better execution time by sacrificing precision, which may lead to = panic > on busy systems with: >=20 > panic: avl_find() succeeded inside avl_add() I don=92t believe that r269223 requires a temporal ordering of the dbufs = in the AVL, just unique entries. So why use an expensive operation like = getting high resolution time? Can=92t we just use a PCPU counter and = tag the dbufs with "CPU# << 48 | PCPU_counter=94? =97 Justin=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?57D656EF-5D6B-428B-9DCE-7FA360B1407F>