Date: Mon, 24 Feb 2014 18:36:06 +0000 From: Mark R V Murray <markm@FreeBSD.org> To: Gleb Smirnoff <glebius@FreeBSD.org> Cc: svn-src-projects@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r262380 - projects/random_number_generator/sys/dev/random Message-ID: <0DE90608-629E-4CF9-8F7F-70F40FEE79D3@FreeBSD.org> In-Reply-To: <20140224110109.GO86937@FreeBSD.org> References: <201402231849.s1NInrvj073433@svn.freebsd.org> <20140224110109.GO86937@FreeBSD.org>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] Hi Gleb On 24 Feb 2014, at 11:01, Gleb Smirnoff <glebius@FreeBSD.org> wrote: > Would buf_ring(9) do the job? If not, may be it is worth to bring it to a state > that would suffice your needs, instead of making another implementation? buf_ring(9) will do the job from a logical/correctness perspective, but is going to be horrendous in the places it needs to be really really really quick ;-). I’ve been asked to not mess around with pointers nearly as much as I did, and buf_ring(9) is a backwards step. I’d be happy to improve buf_ring(9), as you suggest, though. My current implementation is lock-free on the exit-point, and locking on entry is lightweight. Everything internal is 1 static buffer/array and 2 indexes, and the speed for use inside (e.g.) the slab allocators is a much better approximation to what is needed. I still need some things to be faster, so there will be further refinements to make the slab-allocator as happy as I can get it. M -- Mark R V Murray [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBUwuRG958vKOKE6LNAQr2XgP/VC4OZ2F3b24mH5R2F0eyWkUZ32j3sXok s8jyPVQV+SgG5m58HV5siH73fvkc9p0OOxevuF6hx/Q2A0h/XfRxEQX2vpRtj22i x52tVctaAqxeYsZoF84qTyC5iXLtOU6tRnt2BPElMg03pjl76HVstCc1czHmHxbx 6WnEqOhfhVQ= =HIIY -----END PGP SIGNATURE-----help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0DE90608-629E-4CF9-8F7F-70F40FEE79D3>