From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 51AE93B2A4 for ; Mon, 16 Sep 2019 10:01:47 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1568642506; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+AU8qf0l06qzUTBgu01WfMrg8S6bQhSunYp3+EC6ODQ=; b=CAiosMJb1OKkdAPYhDROFN3VucO2IRkcI00NAm7Mt0P6gahxn5dMuH2RR0H8E/EBPdZnw8 CeaNeIsnHkK42b/rQXqeBBl6xPA5jDJ1CMHf0/iDCmY7+/IATyG+UbpRO3Sv5+47TI/mOg lEIrEcDwwWR+mUMdkHl266sgj1Pvk1E= Received: from mail-ed1-f69.google.com (mail-ed1-f69.google.com [209.85.208.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-205-_5FiVdqVPSexWWHjGju8iA-1; Mon, 16 Sep 2019 10:01:42 -0400 Received: by mail-ed1-f69.google.com with SMTP id p55so753edc.5 for ; Mon, 16 Sep 2019 07:01:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:in-reply-to:references:date :message-id:mime-version:content-transfer-encoding; bh=+AU8qf0l06qzUTBgu01WfMrg8S6bQhSunYp3+EC6ODQ=; b=sL6IA9BUL3k7VTlKciNBiv4/hTaRNMGduPTKiOsCv1w9us0J6hyz7w7v9xQ1ySx4mB huN9uZmgT0+ybuRNn0sjXKRV5MfDVuhU3SdE3agmtDe9egXcNVgnc00H9pf60XMZTvWZ gS983oZbWHO6sReqHiezVyHEc9gJgL3fxnhOkdFpP2HBz2gp75muLtkLa336EjvKrS2p yjXOML4aPG17IzFLv/icNSMyZWGCEKWOBDcaD/ogNj3z846dXQtxvssIvJXsLa3vvOS7 4UIGhHLSTnfKdE567STOQ77M37hQhduWYUWai1fWo8Ue7Uwufc0DBsqDdqu4ahdBGajp CpJw== X-Gm-Message-State: APjAAAWeRP4WGDOCXp1YaCBeZvf+MR4PNS8DpBSntRECx+ncGeloXFOe DH4lHhFnQEvksS8VjRz3UC/gueWzwxZhqCM8wUJxMkniZxl4BpyZLC0d1dTAC7mHiPby4mnEC6K TKkXwIb5xMd6jrm45veYO4Q== X-Received: by 2002:a50:cfc7:: with SMTP id i7mr52456990edk.89.1568642501241; Mon, 16 Sep 2019 07:01:41 -0700 (PDT) X-Google-Smtp-Source: APXvYqwH3OJHRriqr4sSEI8Qnq9r/aq0kr0akcs68NkIvCOsMqdhhjn1uJbjgNJN+9d4oSmg7kyGQA== X-Received: by 2002:a50:cfc7:: with SMTP id i7mr52456979edk.89.1568642501067; Mon, 16 Sep 2019 07:01:41 -0700 (PDT) Received: from alrua-x1.borgediget.toke.dk (borgediget.toke.dk. [85.204.121.218]) by smtp.gmail.com with ESMTPSA id oh24sm4349671ejb.79.2019.09.16.07.01.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Sep 2019 07:01:39 -0700 (PDT) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 5FB161800B9; Mon, 16 Sep 2019 16:01:39 +0200 (CEST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Sebastian Gottschall , cake@lists.bufferbloat.net In-Reply-To: References: <2825CE14-2109-4580-A086-9701F4D3ADF0@gmail.com> <18b1c174-b88d-4664-9aa8-9c42925fc14c@www.fastmail.com> <9a90111b-2389-4dc6-8409-18c40f895540@www.fastmail.com> <43F02160-E691-4393-A0C0-8AB4AD962700@gmail.com> <057ea708-6797-23f5-ef01-9d3d7b002578@newmedia-net.de> <878sqomoj4.fsf@toke.dk> X-Clacks-Overhead: GNU Terry Pratchett Date: Mon, 16 Sep 2019 16:01:39 +0200 Message-ID: <87h85cl4qk.fsf@toke.dk> MIME-Version: 1.0 X-MC-Unique: _5FiVdqVPSexWWHjGju8iA-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] cake memory consumption X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2019 14:01:47 -0000 Sebastian Gottschall writes: > Am 16.09.2019 um 14:08 schrieb Toke H=C3=B8iland-J=C3=B8rgensen: >> Sebastian Gottschall writes: >> >>> after we found out serious out of memory issues on smaller embedded >>> devices (128 mb ram) we made some benchmarks with different schedulers >>> with the result that cake takes a serious amount of memory. we use the >>> out of tree cake module and we use it class based since we have complex >>> methods of doing qos per interface, per mac addresse or even per >>> ip/network. so its not just simple cake on a single interface solution. >>> we made some benchmarks with different schedulers. does anybody have a >>> solution for making that better? >>> >>> HTB/FQ_CODEL -------=EF=83=A0 62M >>> HTB/SFQ -------=EF=83=A0 62M >>> HTB/PIE -------=EF=83=A0 62M >>> HTB/FQ_CODEL_FAST -------=EF=83=A0 67M >>> HTB/CAKE -------=EF=83=A0111M >>> >>> HFSC/FQ_CODEL_FAST -------=EF=83=A0 47M >>> HTB/PIE -------=EF=83=A0 49M >>> HTB/SFQ -------=EF=83=A0 50M >>> HFSC /FQ_CODEL -------=EF=83=A0 52M >>> HFSC/CAKE -------=EF=83=A0109M >> How are you measuring the memory usage, and what is your full config for >> each setup? :) > me? nothing. i requested this test from a reporter and he uses just free= =20 > / top. so there is a error tollerance. Ah, I see. So this is just total system memory as reported by top. > but it shows a significant difference between cake and fq_codel etc.=20 > cake is doing a OOM at the end > > for the full report including config screenshots see this=20 > https://svn.dd-wrt.com/ticket/6798#comment:14. it shows also the qos=20 > setup which i can use to reproduce and to > print out the full tc ruleset if required (which it surelly is for you).= =20 > if you want i will recreate this setup and send the tc rules on this > list Yes, please do. The output of 'tc -s qdisc' would be useful as well to see how much memory CAKE itself thinks it's using... Are you setting the memory_limit in your config or relying on CAKE's default? -Toke