From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 98A9E2DF8C for ; Fri, 3 May 2019 19:50:03 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKS-4lrKTAfd for ; Fri, 3 May 2019 19:50:03 -0400 (EDT) Received: from smtp15.mail.ru (smtp15.mail.ru [94.100.176.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id E1DC72DF88 for ; Fri, 3 May 2019 19:50:02 -0400 (EDT) Subject: [tarantool-patches] Re: [PATCH 1/1] small: introduce static allocator References: <50ba091077c074c4eecc1ee63f53d2f4f245bd51.1556466730.git.v.shpilevoy@tarantool.org> <20190503212635.GA16185@atlas> <3ae3f8b3-fb07-5925-27d7-168e857b9d62@tarantool.org> <20190503213613.GA16696@atlas> From: Vladislav Shpilevoy Message-ID: Date: Sat, 4 May 2019 02:49:57 +0300 MIME-Version: 1.0 In-Reply-To: <20190503213613.GA16696@atlas> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: tarantool-patches-bounce@freelists.org Errors-to: tarantool-patches-bounce@freelists.org Reply-To: tarantool-patches@freelists.org List-Help: List-Unsubscribe: List-software: Ecartis version 1.0.0 List-Id: tarantool-patches List-Subscribe: List-Owner: List-post: List-Archive: To: Konstantin Osipov Cc: tarantool-patches@freelists.org On 04/05/2019 00:36, Konstantin Osipov wrote: > * Vladislav Shpilevoy [19/05/04 00:34]: >>> OK to push. >>> >>> Shouldn't you align the address or provide an aligned alloc along >>> with the basic one? >> >> I thought about a function like static_aligned_alloc just like we >> have for region, but was not sure if we need it now. There are no >> code uses old tt_static_buf for data needed alignment. I hoped we >> could implement it on demand. >> >> But if you think we should implement it now, I can do that. >> Should I? > > Previously tt_static_buf allocations were always aligned, since > the next alloc would always allocate at position 0 in the buffer. > Now you provide a general purpose alloc more or less, which can > start at any position in the buffer. I would simple ensure that > static_alloc() is intptr_t aligned. We can add an aligned alloc > later. If we align reserve() or alloc() by default, we would break the pattern, when we do big reserve of maximal size and then lots of small allocs of exact sizes. Works when we do not know how many bytes a big complex object will occupy. We use that for mpstream with obuf, ibuf, region, and somewhere in SQL for pure region without mpstream. All our allocators guarantee now, that if you succeed at a big reserve(), you can consume this memory in multiple allocs, without gaps. Additionally it contradicts with region API (the only allocator, providing aligned allocations) - it has separate reserve + alloc, and aligned_reserve + aligned_alloc. I would rather implement separately normal static_alloc/reserve + static_aligned_alloc/aligned_reserve. Are you okay with that? > > > -- > Konstantin Osipov, Moscow, Russia, +7 903 626 22 32 >