Re: [RFC][PATCH 0/3] TCP/IP Critical socket communication mechanism

On Thu, 15 Dec 2005 06:42:45 +0100
Andi Kleen <ak@xxxxxxx> wrote:

> On Wed, Dec 14, 2005 at 08:30:23PM -0800, David S. Miller wrote:
> > From: Matt Mackall <mpm@xxxxxxxxxxx>
> > Date: Wed, 14 Dec 2005 19:39:37 -0800
> >
> > > I think we need a global receive pool and per-socket send pools.
> >
> > Mind telling everyone how you plan to make use of the global receive
> > pool when the allocation happens in the device driver and we have no
> > idea which socket the packet is destined for? What should be done for
>
> In theory one could use multiple receive queue on intelligent enough
> NIC with the NIC distingushing the sockets.
>
> But that would be still a nasty "you need advanced hardware FOO to avoid
> subtle problem Y" case. Also it would require lots of driver hacking.
>
> And most NICs seem to have limits on the size of the socket tables for this, which
> means you would end up in a "only N sockets supported safely" situation,
> with N likely being quite small on common hardware.
>
> I think the idea of the original poster was that just freeing non critical packets
> after a short time again would be good enough, but I'm a bit sceptical
> on that.
>
> > I truly dislike these patches being discussed because they are a
> > complete hack, and admittedly don't even solve the problem fully. I
>
> I agree.
>
> > I think GFP_ATOMIC memory pools are more powerful than they are given
> > credit for. There is nothing preventing the implementation of dynamic
>
> Their main problem is that they are used too widely and in a lot
> of situations that aren't really critical.

Most of the use of GFP_ATOMIC is by stuff that could fail but can't
sleep waiting for memory. How about adding a GFP_NORMAL for allocations
while holding a lock.

#define GFP_NORMAL (__GFP_NOMEMALLOC)

Then get people to change the unneeded GFP_ATOMIC's to GFP_NORMAL in
places where the error paths are reasonable.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: Custom Thread Pool (by Mr. Jon Skeet) Enhancement
    ... Essentially it receives short socket based ... > connections with an ASCII message, parses that message, does some ... Could you not use asychronous IO again, and keep the thread pool ... Check on completion of a work item the CPU usage and decide whether ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: accessing tcp/ip from a device driver
    ... > inside a device driver, i.e. like open a socket. ... > device driver writing on netbsg.org; ... What you should consider is a user-lever app that opens sockets. ...
    (comp.unix.bsd.netbsd.misc)
  • Re: Available memory and limit on thread creation
    ... >>to send the results back to the correct socket. ... > step of the exec stream you send a packet back to a common port where ... > the packet contain nothing but the id number of the exec. ... purpose socket readers in a pool, another pool to process the received ...
    (comp.lang.java.programmer)
  • [RFC][PATCH 0/3] TCP/IP Critical socket communication mechanism
    ... It uses the critical page pool facility provided by Matt's patches ... This mechanism provides a new socket option SO_CRITICAL that can be used to ... A critical connection used for emergency ... It uses the __GFP_CRITICAL flag introduced in the critical page pool patches ...
    (Linux-Kernel)
  • Re: [RFC][PATCH 0/3] TCP/IP Critical socket communication mechanism
    ... >> I think we need a global receive pool and per-socket send pools. ... > idea which socket the packet is destined for? ... And most NICs seem to have limits on the size of the socket tables for this, ... I think the idea of the original poster was that just freeing non critical packets ...
    (Linux-Kernel)