From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <andi@firstfloor.org>
Received: from mga11.intel.com (mga11.intel.com [192.55.52.93])
	by huchra.bufferbloat.net (Postfix) with ESMTP id A4B6C21F095
	for <codel@lists.bufferbloat.net>; Wed, 11 Jul 2012 11:38:33 -0700 (PDT)
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 11 Jul 2012 11:38:31 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="176136577"
Received: from tassilo.jf.intel.com ([10.7.201.151])
	by fmsmga001.fm.intel.com with ESMTP; 11 Jul 2012 11:38:31 -0700
Received: by tassilo.jf.intel.com (Postfix, from userid 501)
	id 5FAA7241C67; Wed, 11 Jul 2012 11:38:31 -0700 (PDT)
From: Andi Kleen <andi@firstfloor.org>
To: Eric Dumazet <eric.dumazet@gmail.com>
References: <1342021831.3265.8174.camel@edumazet-glaptop>
Date: Wed, 11 Jul 2012 11:38:31 -0700
In-Reply-To: <1342021831.3265.8174.camel@edumazet-glaptop> (Eric Dumazet's
	message of "Wed, 11 Jul 2012 17:50:31 +0200")
Message-ID: <m2r4sirvmg.fsf@firstfloor.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailman-Approved-At: Wed, 11 Jul 2012 11:58:34 -0700
Cc: nanditad@google.com, netdev@vger.kernel.org, codel@lists.bufferbloat.net,
	mattmathis@google.com, ncardwell@google.com,
	David Miller <davem@davemloft.net>
Subject: Re: [Codel] [PATCH v3 net-next] tcp: TCP Small Queues
X-BeenThere: codel@lists.bufferbloat.net
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: CoDel AQM discussions <codel.lists.bufferbloat.net>
List-Unsubscribe: <https://lists.bufferbloat.net/options/codel>,
	<mailto:codel-request@lists.bufferbloat.net?subject=unsubscribe>
List-Archive: <https://lists.bufferbloat.net/pipermail/codel>
List-Post: <mailto:codel@lists.bufferbloat.net>
List-Help: <mailto:codel-request@lists.bufferbloat.net?subject=help>
List-Subscribe: <https://lists.bufferbloat.net/listinfo/codel>,
	<mailto:codel-request@lists.bufferbloat.net?subject=subscribe>
X-List-Received-Date: Wed, 11 Jul 2012 18:38:33 -0000

Eric Dumazet <eric.dumazet@gmail.com> writes:
> +
> +		if (!sock_owned_by_user(sk)) {
> +			if ((1 << sk->sk_state) &
> +			    (TCPF_ESTABLISHED | TCPF_FIN_WAIT1 |
> +			     TCPF_CLOSING | TCPF_CLOSE_WAIT))
> +				tcp_write_xmit(sk,
> +					       tcp_current_mss(sk),
> +					       0, 0,
> +					       GFP_ATOMIC);

Did you have any problems with the GFP_ATOMIC allocation failing here?
I think you move some skb allocs from process context to ATOMIC, right?

It relies on the VM somehow catching up in another context.

May be interesting to try out under very high memory pressure.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only