Hi,
Just added an old network card, RTL-8029(AS), ne2k-pci driver, and tried to
expand the network (failed because I didn't use a cross-over cable).
The code snippet that spat the thing:
/*
* IRQ resend
*
* Is called with interrupts disabled and desc-lock held.
*/
void
On Mon, August 28, 2006 12:22, Peter Zijlstra said:
On Sat, 2006-08-26 at 04:37 +0200, Indan Zupancic wrote:
Why not 'emergency'? Looks like 'emerge' with a typo now. ;-)
hehe, me lazy, you gentoo ;-)
sed -i -e 's/emerg/emregency/g' -e 's/EMERG/EMERGENCY/g' *.patch
I used it for a while
On Mon, August 28, 2006 19:32, Peter Zijlstra said:
Also, I'm really past caring what the thing
is called ;-) But if ppl object I guess its easy enough to run yet
another sed command over the patches.
True, same here.
You can get rid of the memalloc_reserve and vmio_request_queues variables
On Fri, August 25, 2006 17:39, Peter Zijlstra said:
@@ -282,7 +282,8 @@ struct sk_buff {
nfctinfo:3;
__u8pkt_type:3,
fclone:2,
- ipvs_property:1;
+
/* Check if this were the first socks: */
if (nr_socks - socks == 0)
reserve += RX_RESERVE_PAGES;
Can of course be:
if (nr_socks == socks)
reserve += RX_RESERVE_PAGES;
Grumble,
Indan
-
To unsubscribe from this list: send the line
Hello,
Here's a patch to get rid of max_dgram_qlen proc option. All it does is
slow down unix datagram packet sending, without giving the program any
control over it.
Applying it decreases code size, simplifies the code and makes poll
behaviour more logical for connected datagram sockets in
On Tue, August 22, 2006 22:39, Alexey Kuznetsov said:
Feel free to do this correctly. :-)
Deleting wrong code rarely helps.
It is the only protection of commiting infinite amount of memory to a socket.
Doesn't the if (atomic_read(sk-sk_wmem_alloc) sk-sk_sndbuf) check in
On Wed, August 23, 2006 0:34, Alexey Kuznetsov said:
It is the only protection of commiting infinite amount of memory to a
socket.
Doesn't the if (atomic_read(sk-sk_wmem_alloc) sk-sk_sndbuf) check in
sock_alloc_send_pskb()
limit things already?
Unfortunately, it does not. You can open
On Wed, August 23, 2006 1:32, Alexey Kuznetsov said:
Isn't a socket freed until all skb are handled? In which case the limit on
the number of open
files limits the total memory usage? (Same as with streaming sockets?)
Alas. Number of closed sockets is not limited. Actually, it is limited
On Sat, August 12, 2006 17:06, Peter Zijlstra said:
On Sat, 2006-08-12 at 10:41 -0400, Jeff Garzik wrote:
Peter Zijlstra wrote:
Index: linux-2.6/include/linux/gfp.h
===
--- linux-2.6.orig/include/linux/gfp.h 2006-08-12
On Sat, August 12, 2006 16:14, Peter Zijlstra said:
Hi,
here the latest effort, it includes a whole new trivial allocator with a
horrid name and an almost full rewrite of the deadlock prevention core.
This version does not do anything per device and hence does not depend
on the new
On Sat, August 12, 2006 16:14, Peter Zijlstra said:
+struct sk_buff *__alloc_skb(unsigned int size, gfp_t gfp_mask, int fclone)
+{
+ struct sk_buff *skb;
+
+ skb = ___alloc_skb(size, gfp_mask ~__GFP_MEMALLOC, fclone);
+
+ if (!skb (gfp_mask __GFP_MEMALLOC)
On Sat, August 12, 2006 19:44, Peter Zijlstra said:
Euhm, right :-) long comes naturaly when I think about quantities op
pages. The adjust_memalloc_reserve() argument is an increment, a delta;
perhaps I should change that to long.
Maybe, but having 16 TB of reserved memory seems plenty for a
On Sat, August 12, 2006 19:33, Peter Zijlstra said:
Simpler yes, but also more complete; the old patches had serious issues
with the alternative allocation scheme.
It sure is more complete, and looks nicer, but the price is IMHO too high.
I'm curious what those serious issues are, and if they
On Sat, August 12, 2006 20:08, Peter Zijlstra said:
On Sat, 2006-08-12 at 19:54 +0200, Indan Zupancic wrote:
True, but currently memalloc_reserve isn't used in a sensible way,
or I'm missing something.
Well, I'm somewhat reluctant to stick network related code into mm/, it
seems well
On Sat, August 12, 2006 20:47, Peter Zijlstra said:
Ah right, I did that in v3, with a similar comment, but I realised that
the inbound reserve need not be per socket, and that the comment was
ambiguous enough to allow this reading.
True, but better to change the comment than to confuse
On Sat, August 12, 2006 20:54, Peter Zijlstra said:
- single allocation group per packet - that is, when I free a packet
and all its associated object I get my memory back.
This is easy.
- not waste too much space managing the various objects
This too, when ignoring clones and COW.
skb
On Thu, August 10, 2006 18:50, Peter Zijlstra said:
You are right if the reserve wasn't device bound - which I will abandon
because you are right that with multi-path routing, bridge device and
other advanced goodies this scheme is broken in that there is no
unambiguous mapping from sockets to
On Wed, August 9, 2006 2:25, Daniel Phillips said:
Indan Zupancic wrote:
Hello,
Saw the patch on lkml, and wondered about some things.
On Tue, August 8, 2006 21:33, Peter Zijlstra said:
+static inline void dev_unreserve_skb(struct net_device *dev)
+{
+if (atomic_dec_return(dev
On Wed, August 9, 2006 14:54, Peter Zijlstra said:
On Wed, 2006-08-09 at 14:02 +0200, Indan Zupancic wrote:
That avoids lots of checks and should guarantee that the
accounting is correct, except in the case when the IFF_MEMALLOC flag is
cleared and the counter is set to zero manually. Can't
On Wed, August 9, 2006 16:00, Peter Zijlstra said:
On Wed, 2006-08-09 at 15:48 +0200, Indan Zupancic wrote:
On Wed, August 9, 2006 14:54, Peter Zijlstra said:
On Wed, 2006-08-09 at 14:02 +0200, Indan Zupancic wrote:
That avoids lots of checks and should guarantee that the
accounting
On Wed, August 9, 2006 21:45, Peter Zijlstra said:
On Wed, 2006-08-09 at 20:34 +0200, Indan Zupancic wrote:
Why is it needed for the protocol specific code to call dev_unreserve_skb?
It uses this to get an indication of memory pressure; if we have
memalloc'ed skbs memory pressure must be high
22 matches
Mail list logo
