From 2603401fa1f899a8ff60ec6a134d5bd511073a9d Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Tue, 7 Aug 2012 23:25:26 +0200 Subject: IRC. --- hurd/translator/ext2fs/internal_allocator.mdwn | 39 ++++++++++++++++++++++++++ 1 file changed, 39 insertions(+) create mode 100644 hurd/translator/ext2fs/internal_allocator.mdwn (limited to 'hurd/translator/ext2fs') diff --git a/hurd/translator/ext2fs/internal_allocator.mdwn b/hurd/translator/ext2fs/internal_allocator.mdwn new file mode 100644 index 00000000..f3678a28 --- /dev/null +++ b/hurd/translator/ext2fs/internal_allocator.mdwn @@ -0,0 +1,39 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_documentation]] + + +# IRC, freenode, #hurd, 2012-07-30 + + Why for big buffers in ext2fs used own allocator, that just + allocates many pages at once, instead of using malloc? + i.e. can I replace it with malloc, because it just complicates + things? + mcsim: probably because of alignment + what gets complicated by that ? + braunr: than valloc? + braunr: this allocator allows to allocate only buffer with size of + vm_page_size. + valloc just would be clearer. + valloc ? + valloc is obsolete + braunr: than memalign or posix_memalign? + memalign obsolete too... would posix_memalign be eligible? + mcsim: why memalign instead of the custom allocator ? + because, I think, it is clearer. Also, since I need to allocate any + amount of pages, not just one, I have to edit custom allocator. Although + it is not hard, but using ready stuff seems more sane for me. + braunr: ^ + right, but make sure posix_memalign doesn't create too much + overhead + braunr: what kind of overhead? + fragmentation + i assume the glibc implementation is careful about that, but still -- cgit v1.2.3