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 1F8A1298FC for ; Tue, 2 Oct 2018 14:17:01 -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 l4wcheJvZO57 for ; Tue, 2 Oct 2018 14:17:01 -0400 (EDT) Received: from smtp39.i.mail.ru (smtp39.i.mail.ru [94.100.177.99]) (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 D2F3029452 for ; Tue, 2 Oct 2018 14:17:00 -0400 (EDT) Received: by smtp39.i.mail.ru with esmtpa (envelope-from ) id 1g7PEA-0000TO-Fz for tarantool-patches@freelists.org; Tue, 02 Oct 2018 21:16:59 +0300 Date: Tue, 2 Oct 2018 21:16:56 +0300 From: Konstantin Osipov Subject: [tarantool-patches] Re: [PATCH v2 02/11] vinyl: factor load regulator out of quota Message-ID: <20181002181656.GA12422@chai> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: tarantool-patches@freelists.org * Vladimir Davydov [18/09/28 21:00]: > Turned out that throttling isn't going to be as simple as maintaining > the write rate below the estimated dump bandwidth, because we also need > to take into account whether compaction keeps up with dumps. Tracking > compaction progress isn't a trivial task and mixing it in a module > responsible for resource limiting, which vy_quota is, doesn't seem to be > a good idea. Let's factor out the related code into a separate module > and call it vy_regulator. Currently, the new module only keeps track of > the write rate and the dump bandwidth and sets the memory watermark > accordingly, but soon we will extend it to configure throttling as well. OK, if we keep regulator in place there is a few comments about the contents of the patch (i.e. the renames). > - struct vy_quota *q = &env->quota; > + struct vy_regulator *r = &env->regulator; > > - info_table_begin(h, "quota"); > - info_append_int(h, "used", q->used); > - info_append_int(h, "limit", q->limit); > - info_append_int(h, "watermark", q->watermark); > - info_append_int(h, "use_rate", q->use_rate); > - info_append_int(h, "dump_bandwidth", q->dump_bw); > - info_table_end(h); /* quota */ > + info_table_begin(h, "regulator"); > + info_append_int(h, "watermark", r->watermark); > + info_append_int(h, "write_rate", r->write_rate); > + info_append_int(h, "dump_bandwidth", r->dump_bw); I think "watermark" should be now "dump_watermark", sicne simply "watermark" is not specific enough. Is it regulator watermark? A regulator watermark doesn't make any sense to me. The rename should take place across the entire code base imho. > assert(mem_used_after >= mem_used_before); > vy_quota_adjust(&env->quota, tx->write_size, > mem_used_after - mem_used_before); > + vy_regulator_check_watermark(&env->regulator); Like check_dump_watermark. > vy_env_quota_exceeded_cb(struct vy_quota *quota) > { > struct vy_env *env = container_of(quota, struct vy_env, quota); > + vy_regulator_no_memory(&env->regulator); IMHO vy_regulator_quota_exceeded is a better name. -- Konstantin Osipov, Moscow, Russia, +7 903 626 22 32 http://tarantool.io - www.twitter.com/kostja_osipov