netdev - Re: [PATCH 08/17] net: Do not coalesce skbs belonging to PFMEMALLOC sockets

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 20 Jun 2012 15:18:33 +0100
From:	Mel Gorman <mgorman@...e.de>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Linux-MM <linux-mm@...ck.org>,
	Linux-Netdev <netdev@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	David Miller <davem@...emloft.net>, Neil Brown <neilb@...e.de>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Mike Christie <michaelc@...wisc.edu>,
	Eric B Munson <emunson@...bm.net>,
	Sebastian Andrzej Siewior <sebastian@...akpoint.cc>
Subject: Re: [PATCH 08/17] net: Do not coalesce skbs belonging to PFMEMALLOC
 sockets

On Wed, Jun 20, 2012 at 03:51:52PM +0200, Eric Dumazet wrote:
> On Wed, 2012-06-20 at 14:36 +0100, Mel Gorman wrote:
> > The intention was to avoid any coalescing in the input path due to avoid
> > packets that "were held back due to TCP_CORK or attempt at coalescing
> > tiny packet". I recognise that it is clumsy and will take the approach
> > instead of having __tcp_push_pending_frames() use sk_gfp_atomic() in the
> > output path.
> 
> But coalescing in input path needs no additional memory allocation, it
> can actually free some memory.
> 

When I wrote it I thought the timing of the transmission of pending frames
was the problem rather than the actual memory usage. My intention was that
any data related to swapping be handled immediately without delay instead of
deferring until a time when GFP_ATOMIC allocations might fail. I arrived
at this patch because tcp_input.c does call tcp_push_pending_frames()
on the receive path and that led me to believe that coalescing was a
factor.

> And it avoids most of the time the infamous "tcp collapses" that needed
> extra memory allocations to group tcp payload on single pages.
> 
> If you want tcp output path being safer, you should disable TSO/GSO
> because some drivers have special handling for skbs that cannot be
> mapped because of various hardware limitations.
> 

Understood. Thanks for the explanation.

-- 
Mel Gorman
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html