Date: Wed, 13 Aug 2014 23:24:11 -0700 From: Xin Li <delphij@delphij.net> To: John-Mark Gurney <jmg@funkthat.com>, Xin LI <delphij@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r269963 - head/sys/kern Message-ID: <53EC560B.5000104@delphij.net> In-Reply-To: <20140814053518.GO83475@funkthat.com> References: <201408140513.s7E5DPRb069698@svn.freebsd.org> <20140814053518.GO83475@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 8/13/14 10:35 PM, John-Mark Gurney wrote: > Xin LI wrote this message on Thu, Aug 14, 2014 at 05:13 +0000: >> Author: delphij Date: Thu Aug 14 05:13:24 2014 New Revision: >> 269963 URL: http://svnweb.freebsd.org/changeset/base/269963 >> >> Log: Re-instate UMA cached backend for 4K - 64K allocations. New >> consumers like geli(4) uses malloc(9) to allocate temporary >> buffers that gets free'ed shortly, causing frequent TLB shootdown >> as observed in hwpmc supported flame graph. > > Can we do even larger, like 128k for phys io sized blocks? Sure (Actually I'm running with 128k and 256k buckets enabled on my own storage box; with r269964 we can easily add new buckets without actually activating them by default). However, I'm relented to add them right now because the current malloc(9) implementation would use the next bucket size, which is 2x of the previous one, when the requested size is only a little bit larger than the smaller chunk's size. In real world the larger bucket could eat more memory than all smaller but greater than page-sized bucket combined (the actual consumption is still small, though). I think eventually the right way to go is to adopt more sophisticated allocation strategy like the one used in jemalloc(3) and this changeset is more-or-less temporary for now: I committed it mainly because it eliminated a large portion of unwanted TLB shootdowns I have observed with very reasonable overhead (a few megabytes of RAM). > geli can do allocations >128k, which could be broken into two > parts, one in the <8k sized range and the other in 128k... Yes, this is another issue that I'd like to solve. -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJT7FYKAAoJEJW2GBstM+nsfIwP+gI+gPP2msCOIOpYSYK0hP50 xi5Bk4MDOpEZ7J4z4zWwqGXygDdgBUGXTGoAB1+3LwRD4/F+kEVlFFoRuUZTxsBC dstHq9X29omZ8xnLnQ7GTRPWaULHP7gX8RmJvJ8IH2ElYwUwe0whDNIaK4esqKOb Td1Lgse+FcozpMBaP4cIOtTXMBU1xY27n6i9EqXYQL2iuRFrehyD+DHyQ5M6cU5L FdOrX0+SsJ8ybG0KAPRl0VgjZSzBv74AeOz+DOF4EX2YkajcrvTG8JIShyY401Ou WiaE3dMaQvG1InpRH3Yu0twqTsinmu5xvunNJ3/8pE0C+OGSdcvd7Lvt6L4J5Isl f4tcfUbpvV2ja9tIHw//s8YYD6eRdd+AioeOwsOYwEWB9IbG/fE3BZUPKk3Xgtvz /m9SWKzFq8JMYrBOLpGeFSVQvpOHoH3ceiauzL0UqgTbyFX6zQibmpVxhTQLNUYF Fg16hk6HfRmxCQP22OB760pEjIGyQJzDDAjme7XYtkthsqbapU+tJQNb5+MY2T0p nI55dFHxKISBA5dhTNNt22vUN0A7VjKp0kYt9JhtlTJC/SX1BU2O5T1nYa2nsgrK 3xAgmLYBMj9LWl1ncp+/+Yv+FZZ25xgTae2sAGrX2cFHRy6/ifevVpP8BVupw5z0 BPpAtyp11WVwOPB1N4UB =6OMC -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53EC560B.5000104>