From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 3C40621F1AA for ; Thu, 29 Oct 2015 02:56:34 -0700 (PDT) Received: from u-089-d061.biologie.uni-tuebingen.de ([134.2.89.61]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Lxdfb-1aXa8T2okV-017Gwh; Thu, 29 Oct 2015 10:56:30 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: Date: Thu, 29 Oct 2015 10:56:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: =?windows-1252?Q?Dave_T=E4ht?= X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:z7nzZNs2tEaBUAVQtb290U1mo3vyuUFRLdmoqMy3qMio8S8hfv7 qh4hG3eRzIqMaRat2vS7Ll0h7eB4DQf9mo58lfc53JAG4FSPCvEdxDowrciwHOkDSZ2ZGY4 vT2ApUFDLaX1f90z45Gg9+4RU6B0jq7cQ00mfaAfpl04+8LsErMJHQIZYX9PlFElrIOVBUV c7YG9iBtXHQ+jnXTEJGZg== X-UI-Out-Filterresults: notjunk:1;V01:K0:EGJKeL24Wi0=:gdAnqIxRQiS1O22E2wT5f3 N++6ycwY/4P4lTdf3XaL4DymPBMvjXv/3A46lN2Y7FoU68Z3M37ovdot7+1ddQaqiAb3U+Wlr xBuGBUWB5HbHZMManzYz+Ll5ihY+CbVsT1DjP19pgMCViYEKB9RZkCAVw+tLj+F9BHu8GyjRg 32ASpzBJaTxmpOPM0UxqIuLRyheY7gn+Dsgm9qQPyGsMj9Bfq3f1JAGS/Sd6bbjCf/V1lZ4aH y4LmdzTTqsEDE3gusj1vT2Wp5tNdKucXcj/DJxK1baLxfvM2Ru0LCXY2fOOkS1LCcQuJxO7aj Ylv1o3pkMr8t1okfwY52+/L5oRtWipagjKcTa/qCE4hpvHgABYHGKtMFWGx7copfOpAxIiMu+ ZJj/tkFV+eTa29jInPFO7Vow/nW0uQnytT67xFzR/lylqbjYAqlHLWe1tMcRgzEkp16S7AxRV pi6Pa7dZUWgMd3DcQyqbp4cItff8TFyEkOl8Hl4UbamJGjvVdGRTG6AlSdmsAS4HyyMprJ/WW 0Dx0Wf3RacUkjMKUSirsUbMaLjRcOREghgloNWUt5VPDNrqT4i4TfI4eKsfTvfu/TAnzUjeLh Jgj0mdBZIw44JcKPhl7e96RFkXsQXiz9sjGujOGmMucrhScQsUB48Fl2kJ+QLhUU5IcWRyktf dl96ag41p0oSR4EHdJC6jFzhuX+VMebcbX3Qjrsv0EirDFY9Vymkk2TBJhmOWV/O0R7myJrd7 XpbxSRL9nEK3tMv6Fq1Mn6lYtswSklVON98+Blb+gm1A/G77MPozYj5NfyoZyNgNAErcQeqZG e1KLHSE Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] memory X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2015 09:56:57 -0000 Hi Dave, On Oct 29, 2015, at 10:01 , Dave Taht wrote: > There has been so much traffic here that I can't summarize. >=20 > A) But a bit on memory limits - the memory limit enforced in cake is a > sanity check sort of limit. There are *no* allocations of memory in > it. It will not fail itself, due to running out of memory except at > init time. This is all quite interesting and correct; the point I failed to = make clearly it seems, is that a 50MB limit on a 64MB router can not be = called sane or safe, no matter how you slice or dice it=85 It is one = thing having cake tell me that it thinks the limit I gave is to low to = reach full throughput as long as it accepts the given limit. >=20 > So if you run out of memory elsewhere in the system, the normal set of > bad things happen. cake's "sane - and, yes, could use more smarts" > limits can reduce memory pressure elsewhere in the system by > discarding things when it gets irrational, but packet memory tends to > be fragmented and hard to recover cleanly in the first place. To come back to my example, the big issue is that unlike a lot = of other allocations the queue is filled by tpackets generated by = connected machines, it would be sweet if it would be harder for a = mischievous user in my internal network to OOM my router=85 I guess what = I want to say is there is not one size fits all size for a safe limit, = it really depends on the machines memory (on the lower end) and on = expected traffic at the upper end. >=20 > B) Similarly a HUGE waster of memory is small packets, which usually > get a full slab of bytes (2k) to play with on the rx side. This > problem got so bad in some testing that openwrt contains a clever (I > would say that because I wrote it), patch that once we get to tons of > packets more than we think is sane and we get close to running out of > 2k slabs that we start reallocating packets to fit into much smaller > slabs (like 512 bytes) and copying them into those. Clever! This argues for a limit on the sum of skb->true size of = all queued packets instead of just the number of packets. On the other = hand number of packets will not treat small and large packets = differently and hence the number of packets limit should correlate = pretty nicely with the consumed memory. But for this to work cake needs = to interpret the limit as a hard maximum limit. >=20 > so, briefly, memory allocation and release patterns are more complex > than the discussion I sort of saw go by a over the last few days. I know that I am just a layman, but the limit thing does not = seem to be too complex, we are really just talking about a safety valve, = that does not need to be hyper precise, but approximately correlated = with the consumed memory. Currently, setting oldish cake up on in- and = egress would have the worst case queue memory somewhere at (2 * 10240 * = 2) =3D 40960 KB which on a 64MB is already larger than I would prefer = and totally ineffective on a 32MB router ;). I am by the war fine with = cake defaulting to what ever number is deemed good, all I want is to be = able to tell cake something smaller if need be.=20 But than cake is not my baby, and all I can do is try to = convince Jonathan, Toke and you that I believe that while cake=92s = principle should be simplicity in use that does not need to mean no = knobs as long as everything works fine in most cases without the need to = touch those knobs ;) Best Regards Sebastian >=20 > Dave T=E4ht > I just invested five years of my life to making wifi better. And, > now... the FCC wants to make my work, illegal for people to install. > https://www.gofundme.com/savewifi > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake