On Monday 06 August 2007 13:27, Andrew Morton wrote:
> On Mon, 6 Aug 2007 13:19:26 -0700 (PDT) Christoph Lameter wrote:
> > The solution may be as simple as configuring the reserves right and
> > avoid the unbounded memory allocations. That is possible if one
> > would make sure that the network layer triggers reclaim once in a
> > while.
>
> Such a simple fix would be attractive. Some of the net drivers now
> have remarkably large rx and tx queues. One wonders if this is
> playing a part in the problem and whether reducing the queue sizes
> would help.
There is nothing wrong with having huge rx and tx queues, except when
they lie in the vm writeout path. In that case, we do indeed throttle
them to reasonable numbers.
See:
http://zumastor.googlecode.com/svn/trunk/ddsnap/kernel/dm-ddsnap.c
down(&info->throttle_sem);
The only way we have ever gotten ddsnap to run reliably under heavy load
without deadlocking is with Peter's patch set (a distant descendant of
mine from two years or so ago) and we did put a lot of effort into
trying to make congestion_wait and friends do the job instead.
To be sure, it is a small subset of Peter's full patch set that actually
does the job that congestion_wait cannot be made to do, which is to
guarantee that socket->write() is always able to get enough memory to
send out the vm traffic without recursing. What Peter's patches do is
make it _nice_ to fix these problems.
Regards,
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
