netdev
[Top] [All Lists]

Re: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics

To: Andi Kleen <ak@xxxxxx>
Subject: Re: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics
From: Andrea Arcangeli <andrea@xxxxxxx>
Date: Mon, 28 Mar 2005 18:22:00 +0200
Cc: Rik van Riel <riel@xxxxxxxxxx>, Dmitry Yusupov <dmitry_yus@xxxxxxxxx>, mpm@xxxxxxxxxxx, michaelc@xxxxxxxxxxx, open-iscsi@xxxxxxxxxxxxxxxx, James.Bottomley@xxxxxxxxxxxxxxxxxxxxx, ksummit-2005-discuss@xxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <m1zmwn21hk.fsf@xxxxxx>
References: <20050324215922.GT14202@xxxxxxxxxxxxxx> <424346FE.20704@xxxxxxxxxxx> <20050324233921.GZ14202@xxxxxxxxxxxxxx> <20050325034341.GV32638@xxxxxxxxx> <20050327035149.GD4053@xxxxxxxxx> <20050327054831.GA15453@xxxxxxxxx> <1111905181.4753.15.camel@mylaptop> <20050326224621.61f6d917.davem@xxxxxxxxxxxxx> <Pine.LNX.4.61.0503272245350.30885@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <m1zmwn21hk.fsf@xxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.9i
On Mon, Mar 28, 2005 at 06:12:39PM +0200, Andi Kleen wrote:
> So in short using mempools on receiving is not needed.

I think you are assuming that there's still some atomic memory available
sometime in the future to allocate the skb for the ack, this isn't
necessairly true.

I outlined an algo that thanks to proper mempool-like reservation and
random picking of all mempool registered on a single nic, will avoid the
deadlock for receive. The less mempools there are and the bigger they
are, the faster it will recover.

<Prev in Thread] Current Thread [Next in Thread>