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

[Matt Mackall <mpm@selenic.com>]

On Tue, Mar 29, 2005 at 06:00:11PM -0500, jamal wrote:
> On Tue, 2005-03-29 at 17:00, Rik van Riel wrote:
> 
> >   However, we often will need
> > to get the packets off the network card before we can decide
> > whether or not they're high priority.
> 
> True - although one could argue that with NAPI that decision would be a
> few opcodes away if you install the ingress qdisc. 
> So you may end up allocing only to free a few cycles later. Increased
> memory traffic but the discard happens sufficiently early for a s/ware
> only solution and CPU cycles not burnt as much.
[...]

I think we first need a software solution that makes no special
assumptions about hardware capabilities.
 
> > Also, there can be multiple high priority sockets, and we
> > need to ensure they all make progress.  Hence the mempool
> > idea.
> 
> Sorry missed the early part of this thread: mempool is some
> strict priority scheme for mem allocation?

A mempool is a private allocation pool that attempts to maintain a
reserve of N objects. Various users in the kernel already. See
mm/mempool.c.

> For Sockets: If there was a "control" arbitrator preferably in user
> space which would install - after a socket open - both network ingress
> and/or egress rules for prioritization then wouldnt that suffice?

Generally, we don't want any special handling except when we're
effectively OOM.

-- 
Mathematics is the supreme nostalgia of our time.