From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from [87.239.111.99] (localhost [127.0.0.1]) by dev.tarantool.org (Postfix) with ESMTP id 9A16670202; Wed, 24 Feb 2021 01:19:09 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 9A16670202 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1614118749; bh=8ke1UNcmwybY0g6JJsIdJuN9EM513aQiCH09yiGUCGE=; h=To:Cc:References:Date:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=Y20ZG0Qk40RE8oem8hlAHLBtIDoalnFrHonTO2noaJlRJcrR40wsCQukvUh2tuLg9 4bRDVufcR3PkzRQ9wSN4O3GBkqw8Bk7YKNw+d10xakOVg48oWjsecfmaE0l9hPxAFT 3jJYtQW2Aam6IvGC3cXcVVraa5gwEePq2CourJ4I= Received: from smtp53.i.mail.ru (smtp53.i.mail.ru [94.100.177.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 4935C70202 for ; Wed, 24 Feb 2021 01:19:08 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 4935C70202 Received: by smtp53.i.mail.ru with esmtpa (envelope-from ) id 1lEg1L-00059q-3D; Wed, 24 Feb 2021 01:19:08 +0300 To: Serge Petrenko , gorcunov@gmail.com Cc: tarantool-patches@dev.tarantool.org References: <20210211121750.46298-1-sergepetrenko@tarantool.org> Message-ID: <77af94ed-71eb-74e5-da73-7ae7286bfeb1@tarantool.org> Date: Tue, 23 Feb 2021 23:19:04 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD975C3EC174F5669221340953D8FEAAFCA26BB79E5C093AA91182A05F5380850400552E5D9EF6F522F9976ABE56F6736B6CBF63EC67D1153AA311F31ADDFCF1634 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7ACA11F7F2395C8CCEA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F79006378B49D47CE295E66E8638F802B75D45FF5571747095F342E8C7A0BC55FA0FE5FC61D9FADA98E6539AB63BDF107EC46F2752E07A4B3AB14F40389733CBF5DBD5E913377AFFFEAFD269A417C69337E82CC2CC7F00164DA146DAFE8445B8C89999729449624AB7ADAF37F6B57BC7E64490611E7FA7ABCAF51C92176DF2183F8FC7C0D9442B0B5983000E8941B15DA834481F9449624AB7ADAF37BA3038C0950A5D3613377AFFFEAFD2691661749BA6B97735BCF2C0F5768D5B7A7B076A6E789B0E97A8DF7F3B2552694A1E7802607F20496D49FD398EE364050F91ADC097FE2C3A08A68A47777D5C6D9CB3661434B16C20AC78D18283394535A975ECD9A6C639B01BC09775C1D3CA48CFC74813BC7F81EC8435872C767BF85DA22EF20D2F80756B5F40A5AABA2AD3711975ECD9A6C639B01B78DA827A17800CE7D9D2E6C9A5E65EE7731C566533BA786A40A5AABA2AD371193C9F3DD0FB1AF5EB417FD7EC7EC0BD913C9F3DD0FB1AF5EB4E70A05D1297E1BBCB5012B2E24CD356 X-B7AD71C0: 14C14B24D00AF5AC321EF223B8115265C69B993890792DF82CDD5689AFBDA7A24A6D60772A99906F8E1CD14B953EB46DF0912CC447CC25C5355D89D7DBCDD132 X-C1DE0DAB: 0D63561A33F958A5DC088DB6A89C44F060750BE80C161E7ED95485D87C62246ED59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA7557E988E9157162368E8E86DC7131B365E7726E8460B7C23C X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D341E2D05735FCBECD12CD9A31D74F47EAFE7ABEEEB51F399003AAB74A2832FD57A29BF7EE2608C4CD61D7E09C32AA3244CFFFC1358413468F96F1426CB558BDC1C725D5B54B2FE4575FACE5A9C96DEB163 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojyK6JYJ15DtIu2SvT/6zybg== X-Mailru-Sender: 504CC1E875BF3E7D9BC0E5172ADA31105B0C2DDF05526F63BEE75C04931CB8EEAF7FB42BDCBFC19707784C02288277CA03E0582D3806FB6A5317862B1921BA260ED6CFD6382C13A6112434F685709FCF0DA7A0AF5A3A8387 X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH v2] wal: introduce limits on simultaneous writes X-BeenThere: tarantool-patches@dev.tarantool.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Vladislav Shpilevoy via Tarantool-patches Reply-To: Vladislav Shpilevoy Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" Hi! Thanks for the patch! >>> diff --git a/src/box/journal.c b/src/box/journal.c >>> index cb320b557..49441e596 100644 >>> --- a/src/box/journal.c >>> +++ b/src/box/journal.c >>> @@ -55,3 +55,66 @@ journal_entry_new(size_t n_rows, struct region *region, >>>                    complete_data); >>>       return entry; >>>   } >>> + >>> +struct journal_queue_entry { >>> +    /** The fiber waiting for queue space to free. */ >>> +    struct fiber *fiber; >>> +    /** Whether the fiber should be waken up regardless of queue size. */ >>> +    bool is_ready; >>> +    /** A link in all waiting fibers list. */ >>> +    struct rlist in_queue; >>> +}; >>> + >>> +/** >>> + * Wake up the next waiter in journal queue. >>> + */ >>> +static inline void >>> +journal_queue_wakeup_next(struct rlist *link, bool force_ready) >> 1. The flag is known in all usage places at compilation time. Is it >> possible to split the function into force/normal versions? The same >> for journal_queue_wakeup() from which this runtime uncertainty arises. > > Actually, the parameter is not known at compile time when wakeup_next() > is called from journal_wait_queue(). For now wakeup_next() only has a single > check for force_ready, so moving the check outside would only increase the > number of branches. > > journal_queue_wakeup() is called only once per a whole queue wakeup, so > I suppose it doesn't hurt much it has a compile-time known parameter. Is it called once? Then why does it have `if (current_journal->queue_is_woken)` check? >>> +{ >>> +    /* Empty queue or last entry in queue. */ >>> +    if (link == rlist_last(¤t_journal->waiters)) { >> 2. I am not sure I understand what is happening here. Why is this >> function in one place called with the pointer at the list itself, >> and in another place with the pointer at one element? > > Well, -> next is the fist list entry, right? Perhaps. TBH, I don't remember and when see such tricky things in the code, it takes time to understand it. > In queue_wakeup() I wake the first waiter up. > > Once any waiter gets woken up, it wakes up the next waiter. > Which is -> next. > > That's why I have a common helper for these two cases. Ok, I see now. But it seems you could make it simpler, right? ==================== @@ -69,10 +69,10 @@ struct journal_queue_entry { * Wake up the next waiter in journal queue. */ static inline void -journal_queue_wakeup_next(struct rlist *link, bool force_ready) +journal_queue_wakeup_first(bool force_ready) { /* Empty queue or last entry in queue. */ - if (link == rlist_last(¤t_journal->waiters)) { + if (rlist_empty(¤t_journal->waiters)) { current_journal->queue_is_woken = false; return; } @@ -97,7 +97,7 @@ journal_queue_wakeup(bool force_ready) if (current_journal->queue_is_woken) return; current_journal->queue_is_woken = true; - journal_queue_wakeup_next(¤t_journal->waiters, force_ready); + journal_queue_wakeup_first(force_ready); } void @@ -114,7 +114,7 @@ journal_wait_queue(void) while (journal_queue_is_full() && !entry.is_ready) fiber_yield(); - journal_queue_wakeup_next(&entry.in_queue, entry.is_ready); assert(&entry.in_queue == rlist_first(¤t_journal->waiters)); rlist_del(&entry.in_queue); + journal_queue_wakeup_first(entry.is_ready); } ==================== (I didn't test it.) >> 5. Can rlist_del be done along with fiber_wakeup()? Then you >> wouldn't need is_woken maybe. > > Looks like it can't. > Say we have only one waiter. And remove it from the list on wakeup. > The list would become empty and there'd be no way to check whether > journal has any waiters, and we may reorder the entries (put new ones before > the waiting one). This is not necessarily bad, because I put entries into queue > before txn_begin(), but someone may call journal_wait_queue() from inside the > transaction, or right before txn_commit(). Then it might be bad to put other > transactions before this one. Order change is definitely not acceptable. > So while removing is_woken we would have to introduce queue_has_waiters flag for > the sake of this single waiter. It would rather become a counter - number of waiters. Because there can be many. But yeah, I see the problem. >>> +} >>> + >>> +/** >>> + * Check whether anyone is waiting for the journal queue to empty. If there are >>> + * other waiters we must go after them to preserve write order. >>> + */ >>> +static inline bool >>> +journal_queue_has_waiters(void) >>> +{ >>> +    return !rlist_empty(¤t_journal->waiters); >>> +} >>> + >>> +/** Yield until there's some space in the journal queue. */ >>> +void >>> +journal_wait_queue(void); >>> + >>> +/** Set maximal journal queue size in bytes. */ >>> +static inline void >>> +journal_queue_set_max_size(struct journal *j, int64_t size) >> 7. Why do we have journal parameter here, but don't have it in >> the other functions? The same journal_queue_set_max_len. > > This is my attempt to make sure only wal_writer's journal has a queue. > I explicitly set queue_max_... parameters only for wal_writer's journal. > And then there's an assert that journal_queue_set_...() is only called with > the current journal. Or the assertion could be done in wal_set_queue_*() functions. To keep the journal API consistent. I just realized, journal can be easily unit-tested. It does not depend on anything except small/ and core/ libs. Although seems like a lot of work so maybe not now. Probably later, for something more complex and harder to test via functional tests. However if you would write tests now, it would be greatly appreciated. >>> +{ >>> +    assert(j == current_journal); >>> +    j->queue_max_size = size; >>> +    if (journal_queue_has_waiters() && !journal_queue_is_full()) >>> +        journal_queue_wakeup(false); >>> +} >>> @@ -159,6 +264,12 @@ journal_write(struct journal_entry *entry) >>>   static inline int >>>   journal_write_async(struct journal_entry *entry) >>>   { >>> +    /* >>> +     * It's the job of the caller to check whether the queue is full prior >>> +     * to submitting the request. >> 8. Maybe add an assert though. > > I wanted to, but it's impossible. > The queue may be full when all the waiters are forcefully waken up by a > synchronous commit. And it's hard to tell whether it was a "force" wakeup > or not. So let's just hope noone misuses this API. Yeah, I see now. > Or, even better, I can remove is_ready field from queue entries and add a new field > to the journal: queue_is_ready or something. And addition to queue_is_awake. > Then every entry will check queue_is_ready instead of entry.is_ready and > it'll be possible to add an assert here: !journal_queue_is_full || journal_queue_is_ready > Looks like this'll also allow us to extract queue_wakeup_(next)_force, like you suggested > in paragraph 1. > What do you think ? Sounds good, worth doing. See 2 comments below. >>> +     */ >>> +    journal_queue_on_append(entry); >>> + >>>       return current_journal->write_async(current_journal, entry); >>>   }> diff --git a/src/box/applier.cc b/src/box/applier.cc > index 553db76fc..7c2452d2b 100644 > --- a/src/box/applier.cc > +++ b/src/box/applier.cc > @@ -967,6 +967,15 @@ applier_apply_tx(struct applier *applier, struct stailq *rows) > goto success; > } > > + /* > + * Do not spam WAL with excess write requests, let it process what's > + * piled up first. > + * This is done before opening the transaction to avoid problems with > + * yielding inside it. > + */ > + if (journal_queue_is_full()) > + journal_wait_queue(); 1. I just noticed you do the waiting before starting the transaction. In case of Vinyl the transaction can yield. So by the time you get to commit, the queue could be full. Don't know what to do with this. We can't wait before txn_commit_async() because it would kill the memtx transactions. Maybe we could not to care now. Because overpopulation never will exceed number of appliers, which is tiny. But when async transactions will go to the public API, we will face this issue anyway. I assume we will need to extract txn_prepare to the "public" part of txn.h and use it separately from writing to the journal. So in our code it would look like this: sync: txn_begin() ... txn_commit() async: txn_begin() ... txn_prepare() journal_wait() txn_persist() or something similar. But don't know for sure. Summary: leave it as is if don't want to tear commit_async() and commit() up into parts now. > + > /** > * Explicitly begin the transaction so that we can > * control fiber->gc life cycle and, in case of apply > diff --git a/src/box/journal.h b/src/box/journal.h > index 5d8d5a726..d295dfa4b 100644 > --- a/src/box/journal.h > +++ b/src/box/journal.h > @@ -159,6 +264,12 @@ journal_write(struct journal_entry *entry) > static inline int > journal_write_async(struct journal_entry *entry) > { > + /* > + * It's the job of the caller to check whether the queue is full prior > + * to submitting the request. > + */ > + journal_queue_on_append(entry); > + > return current_journal->write_async(current_journal, entry); 2. What if write_async() is called by some applier when the queue is not full, but also not empty? It seems it will bypass the existing waiters and lead to the transaction order change. No? I start thinking that we need to queue the journal_entry objects right in the journal object. So if their queue is not empty, journal_write_async() adds the entry to the queue and does not call write_async(). Also would be cool to add a test how the applier can reorder WAL writes in the current patch.