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 check_irq_resend(stru
On Tue, August 29, 2006 11:49, Peter Zijlstra said:
> On Tue, 2006-08-29 at 02:01 +0200, Indan Zupancic wrote:
>> Good that you're aware of it. Thing is, how much sense does the split-up into
>> adjust_memalloc_reserve() and sk_adjust_memalloc() make at this point? Why
>>
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 var
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' -
> /* 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 "unsubs
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;
> +
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 lim
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 do
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
sock_allo
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 regar
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.
> sk
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 peop
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 re
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 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 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) && memall
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 netd
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 200
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
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 sk
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
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
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(stru
23 matches
Mail list logo
