Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1273975 > unrolled thread
| Started by | Vladimir Davydov <vdavydov@virtuozzo.com> |
|---|---|
| First post | 2015-11-20 12:00 +0100 |
| Last post | 2015-11-20 19:50 +0100 |
| Articles | 2 — 2 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH 08/14] net: tcp_memcontrol: sanitize tcp memory accounting callbacks Vladimir Davydov <vdavydov@virtuozzo.com> - 2015-11-20 12:00 +0100
Re: [PATCH 08/14] net: tcp_memcontrol: sanitize tcp memory accounting callbacks Johannes Weiner <hannes@cmpxchg.org> - 2015-11-20 19:50 +0100
| From | Vladimir Davydov <vdavydov@virtuozzo.com> |
|---|---|
| Date | 2015-11-20 12:00 +0100 |
| Subject | Re: [PATCH 08/14] net: tcp_memcontrol: sanitize tcp memory accounting callbacks |
| Message-ID | <qwRA7-67v-27@gated-at.bofh.it> |
On Thu, Nov 12, 2015 at 06:41:27PM -0500, Johannes Weiner wrote: > There won't be a tcp control soft limit, so integrating the memcg code > into the global skmem limiting scheme complicates things > unnecessarily. Replace this with simple and clear charge and uncharge > calls--hidden behind a jump label--to account skb memory. > > Note that this is not purely aesthetic: as a result of shoehorning the > per-memcg code into the same memory accounting functions that handle > the global level, the old code would compare the per-memcg consumption > against the smaller of the per-memcg limit and the global limit. This > allowed the total consumption of multiple sockets to exceed the global > limit, as long as the individual sockets stayed within bounds. After > this change, the code will always compare the per-memcg consumption to > the per-memcg limit, and the global consumption to the global limit, > and thus close this loophole. > > Without a soft limit, the per-memcg memory pressure state in sockets > is generally questionable. However, we did it until now, so we > continue to enter it when the hard limit is hit, and packets are > dropped, to let other sockets in the cgroup know that they shouldn't > grow their transmit windows, either. However, keep it simple in the > new callback model and leave memory pressure lazily when the next > packet is accepted (as opposed to doing it synchroneously when packets > are processed). When packets are dropped, network performance will > already be in the toilet, so that should be a reasonable trade-off. > > As described above, consumption is now checked on the per-memcg level > and the global level separately. Likewise, memory pressure states are > maintained on both the per-memcg level and the global level, and a > socket is considered under pressure when either level asserts as much. > > Signed-off-by: Johannes Weiner <hannes@cmpxchg.org> It leaves the legacy functionality intact, while making the code look much better. Reviewed-by: Vladimir Davydov <vdavydov@virtuozzo.com> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [next] | [standalone]
| From | Johannes Weiner <hannes@cmpxchg.org> |
|---|---|
| Date | 2015-11-20 19:50 +0100 |
| Message-ID | <qwYUW-2xv-17@gated-at.bofh.it> |
| In reply to | #1273975 |
On Fri, Nov 20, 2015 at 01:58:57PM +0300, Vladimir Davydov wrote: > On Thu, Nov 12, 2015 at 06:41:27PM -0500, Johannes Weiner wrote: > > There won't be a tcp control soft limit, so integrating the memcg code > > into the global skmem limiting scheme complicates things > > unnecessarily. Replace this with simple and clear charge and uncharge > > calls--hidden behind a jump label--to account skb memory. > > > > Note that this is not purely aesthetic: as a result of shoehorning the > > per-memcg code into the same memory accounting functions that handle > > the global level, the old code would compare the per-memcg consumption > > against the smaller of the per-memcg limit and the global limit. This > > allowed the total consumption of multiple sockets to exceed the global > > limit, as long as the individual sockets stayed within bounds. After > > this change, the code will always compare the per-memcg consumption to > > the per-memcg limit, and the global consumption to the global limit, > > and thus close this loophole. > > > > Without a soft limit, the per-memcg memory pressure state in sockets > > is generally questionable. However, we did it until now, so we > > continue to enter it when the hard limit is hit, and packets are > > dropped, to let other sockets in the cgroup know that they shouldn't > > grow their transmit windows, either. However, keep it simple in the > > new callback model and leave memory pressure lazily when the next > > packet is accepted (as opposed to doing it synchroneously when packets > > are processed). When packets are dropped, network performance will > > already be in the toilet, so that should be a reasonable trade-off. > > > > As described above, consumption is now checked on the per-memcg level > > and the global level separately. Likewise, memory pressure states are > > maintained on both the per-memcg level and the global level, and a > > socket is considered under pressure when either level asserts as much. > > > > Signed-off-by: Johannes Weiner <hannes@cmpxchg.org> > > It leaves the legacy functionality intact, while making the code look > much better. > > Reviewed-by: Vladimir Davydov <vdavydov@virtuozzo.com> Thank you very much! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web