From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Hopwood Subject: Re: [PATCH 3/3] Replace slab.c with a very simpleallocator. Date: Fri, 04 Feb 2005 02:11:50 +0000 Message-ID: <4202D9E6.2060808@blueyonder.co.uk> References: <20050203194406.GB18587@dront> Reply-To: david.nospam.hopwood@blueyonder.co.uk Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit In-Reply-To: <20050203194406.GB18587@dront> Sender: xen-devel-admin@lists.sourceforge.net Errors-To: xen-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: xen-devel@lists.sourceforge.net List-Id: xen-devel@lists.xenproject.org ultraptr@pacbell.net wrote: > I wonder what are reasons for this replacement. From outside it looks like > proven and fast slab allocator is being replaced with slow and new one just > for sake of size and beauty of source codes? Read the paper describing the original version of the slab allocator (http://citeseer.ist.psu.edu/bonwick94slab.html), and then look at how it is used in Xen (the calls that are being replaced by xmalloc in the patch). From this it is clear that the feature that results in most of the allocator's complexity (retaining parts of the initialized state of objects to reduce the cost of reinitialization) is not used at all by Xen. -- David Hopwood ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl