Date: Fri, 15 Sep 2023 11:27:54 +0200 From: Alexander Leidinger <Alexander@Leidinger.net> To: "Mathew, Cherry G.*" <c@bow.st> Cc: freebsd-hackers@freebsd.org, adridg@freebsd.org Subject: Re: ARC model specified in spinroot/promela Message-ID: <d8a86c85173205115faa6d71cb4ef4a1@Leidinger.net> In-Reply-To: <854jjw3jjy.fsf@bow.st> References: <85jzt96qjz.fsf@bow.st> <9c424a574cdd39fc879c9ed9192556c0@Leidinger.net> <858r9o6ee0.fsf@bow.st> <c2197ad9446eca4edae2db09a859d66b@Leidinger.net> <85pm304dzi.fsf@bow.st> <85a5u22oxx.fsf@bow.st> <85y1hjecna.fsf@bow.st> <85o7icapb8.fsf@bow.st> <854jjw3jjy.fsf@bow.st>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_0f4fe8cac9e4b430b5cf98fab1201ebc Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Am 2023-09-14 16:40, schrieb Mathew, Cherry G.*: > A few things remain WIP. Obviously, this is a "toy" model - it has > stack > based "memory" management, and a directory buffer size of 64. So that > needs to be hammered on a bit more. Further, I'm keen to now dip my > toes > into re-entrancy. If you noticed in the earlier patches, there were > model routines for "mutex_enter()/mutex_exit()". I'll re-look these and > play around a little bit with concurrent entry of ARC() (ARC() is now > strictly entered sequentially in a loop - see arc.drv). Once things > settle down, I will look at making an actual block disk driver with an > ARC(9) managed cache using this code. Without having looked at anything in the code, and now with your comment about an "actual block disk driver"... AFAIR your ARC is based upon the paper, and this is not used anywhere in FreeBSD. ZFS is using a modified/adapted version of the ARC. What you are describing sounds a bit like our buffer cache (https://wiki.freebsd.org/BasicVfsConcepts#:~:text=Buffer%20cache%20is%20a%20layer,on%20a%20vnode%2Blbn%20basis.), but our buffer cache is not an ARC, it is AFAIR LRU eviction based. I fully understand that you are far away from doing real modelling of such complex parts as the VFS parts of FreeBSD, but maybe this info gives a hint in terms of looking into some parts and see if you can adopt some parts in terms of design which can be anhanced later on to some real FreeBSD stuff... Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_0f4fe8cac9e4b430b5cf98fab1201ebc Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmUEI6wACgkQEg2wmwP4 2IZeVw//YeFoHw+kZDn3xIRjwpXquO8rxx5OhwcUBNPEH3/KtFKWe7V8sY1f9cK/ EiFgxB8uftybbDhJ9l2Fg8xSLrsTzPlh5k7HpJ21eEL7t4Fa8LUPBixTuP3rwSNW JOpGcI//WoEdwMEPR8Ok4wVgpVdqFt6fh4DXnZcposjkukA+8oS4J9eZ/5LEpGG4 ddjhnQrpAwRGpE3VPeWHhO1RGcQveocUGvsO2PqQ/3xVeqQIr0ubjha0DDVoyqzo jY8QFjCSYERNkcBtQUe/y+mDJqaZaqHGXV1kWG4yXw1HXo3YmriA1NF8BUYIRy/T dxaF2wKhxhLchntkda2UgNY2/4zJYFP+VE2aniENGRVaP9z4FxJWJ4notVhqmsRK DijaKSPJpnPd7asgfPQ16lFB0arjXeyhKAGncOtDA8IcYhM0n/vcrXreL+KhL5Ea NpakUH0hDE55sDpOVAVnfX75BttYw1casGts/bMbzKkAl1P0XrfQR5NZbl2fz3H7 KlGWN0HHQpCvL0Nxuj8MJeUhJnK3NgX2t1HxQOlF5pE5sslPP3eeIF3xeBvAxSYb TCtNXwKDAMGOzXTPoeoNL1oyYShfTPo6lxREYXMeS2M5+3R12qa+pUS8UMux9SVy lqQBVgBMHWruxiqUx0Cs2iQKm5KyM/RnU0OFHliCWN2jL6CHn1A= =gOUU -----END PGP SIGNATURE----- --=_0f4fe8cac9e4b430b5cf98fab1201ebc--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d8a86c85173205115faa6d71cb4ef4a1>