From: Konstantin Osipov <kostja@tarantool.org>
To: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Cc: tarantool-patches@freelists.org
Subject: [tarantool-patches] Re: [PATCH 1/1] small: introduce static allocator
Date: Sat, 4 May 2019 09:53:36 +0300 [thread overview]
Message-ID: <20190504065336.GC16696@atlas> (raw)
In-Reply-To: <b34f6cdf-3e39-237f-1ba1-b50b06e89acc@tarantool.org>
* Vladislav Shpilevoy <v.shpilevoy@tarantool.org> [19/05/04 09:38]:
> >>>
> >>> 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.
On this argument... to use static alloc in mpstream, not aligning
the return value is not enough.
You actually need something a batch alloc API, something
like:
- static_alloc_begin_batch() - resets the buffer and sets the
position to 0,
- static_alloc_alloc_batch() - alloc memory, but return error if
allocation would wrap around, since we need to make sure all
allocation in a batch stay valid
- static_alloc_end_batch() - finish allocating memory within
a batch
Otherwise, how do you guarantee that a subsequent alloc used by
mpstream doesn't wrap the static buffer around and begins
overwriting it?
--
Konstantin Osipov, Moscow, Russia, +7 903 626 22 32
prev parent reply other threads:[~2019-05-04 6:53 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-28 18:41 [tarantool-patches] " Vladislav Shpilevoy
2019-05-02 15:43 ` [tarantool-patches] " Vladislav Shpilevoy
2019-05-03 21:26 ` Konstantin Osipov
2019-05-03 21:32 ` Vladislav Shpilevoy
2019-05-03 21:36 ` Konstantin Osipov
2019-05-03 23:49 ` Vladislav Shpilevoy
2019-05-04 6:50 ` Konstantin Osipov
2019-05-04 18:09 ` Vladislav Shpilevoy
2019-05-04 6:53 ` Konstantin Osipov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190504065336.GC16696@atlas \
--to=kostja@tarantool.org \
--cc=tarantool-patches@freelists.org \
--cc=v.shpilevoy@tarantool.org \
--subject='[tarantool-patches] Re: [PATCH 1/1] small: introduce static allocator' \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox