From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964905AbVLNTUT (ORCPT ); Wed, 14 Dec 2005 14:20:19 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S964904AbVLNTUT (ORCPT ); Wed, 14 Dec 2005 14:20:19 -0500 Received: from e36.co.us.ibm.com ([32.97.110.154]:34772 "EHLO e36.co.us.ibm.com") by vger.kernel.org with ESMTP id S964900AbVLNTUS (ORCPT ); Wed, 14 Dec 2005 14:20:18 -0500 In-Reply-To: <20051214184147.GO23384@wotan.suse.de> To: Andi Kleen Cc: Andi Kleen , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, netdev-owner@vger.kernel.org, sri@us.ibm.com MIME-Version: 1.0 Subject: Re: [RFC][PATCH 0/3] TCP/IP Critical socket communication mechanism X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: David Stevens Date: Wed, 14 Dec 2005 11:20:59 -0800 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.53HF654 | July 22, 2005) at 12/14/2005 12:21:07, Serialize complete at 12/14/2005 12:21:07 Content-Type: text/plain; charset="US-ASCII" Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > It has a lot > more users that compete true, but likely the set of GFP_CRITICAL users > would grow over time too and it would develop the same problem. No, because the critical set is determined by the user (by setting the socket flag). The receive side has some things marked as "critical" until we have processed enough to check the socket flag, but then they should be released. Those short-lived allocations and frees are more or less 0 net towards the pool. Certainly, it wouldn't work very well if every socket is marked as "critical", but with an adequate pool for the workload, I expect it'll work as advertised (esp. since it'll usually be only one socket associated with swap management that'll be critical). +-DLS