On Thu, 2007-01-18 at 13:41 +0300, Evgeniy Polyakov wrote:
> > > What about 'level-7' ack as you described in introduction?
> >
> > Take NFS, it does full data traffic in kernel.
>
> NFS case is exactly the situation, when you only need to generate an ACK.
No it is not, it needs the full RPC re
On Wed, Jan 17, 2007 at 10:07:28AM +0100, Peter Zijlstra ([EMAIL PROTECTED])
wrote:
> > You operate with 'current' in different contexts without any locks which
> > looks racy and even is not allowed. What will be 'current' for
> > netif_rx() case, which schedules softirq from hard irq context -
>
On Wed, 2007-01-17 at 10:12 +0100, Pavel Machek wrote:
> Hi!
>
> > These patches implement the basic infrastructure to allow swap over
> > networked
> > storage.
> >
> > The basic idea is to reserve some memory up front to use when regular memory
> > runs out.
> >
> > To bound network behaviour
Hi!
> These patches implement the basic infrastructure to allow swap over networked
> storage.
>
> The basic idea is to reserve some memory up front to use when regular memory
> runs out.
>
> To bound network behaviour we accept only a limited number of concurrent
> packets and drop those packe
On Wed, 2007-01-17 at 07:54 +0300, Evgeniy Polyakov wrote:
> On Tue, Jan 16, 2007 at 05:08:15PM +0100, Peter Zijlstra ([EMAIL PROTECTED])
> wrote:
> > On Tue, 2007-01-16 at 18:33 +0300, Evgeniy Polyakov wrote:
> > > On Tue, Jan 16, 2007 at 02:47:54PM +0100, Peter Zijlstra ([EMAIL
> > > PROTECTED]
On Tue, Jan 16, 2007 at 05:08:15PM +0100, Peter Zijlstra ([EMAIL PROTECTED])
wrote:
> On Tue, 2007-01-16 at 18:33 +0300, Evgeniy Polyakov wrote:
> > On Tue, Jan 16, 2007 at 02:47:54PM +0100, Peter Zijlstra ([EMAIL
> > PROTECTED]) wrote:
> > > > > + if (unlikely(skb->emergency))
> > > > > +
On Tue, 2007-01-16 at 18:33 +0300, Evgeniy Polyakov wrote:
> On Tue, Jan 16, 2007 at 02:47:54PM +0100, Peter Zijlstra ([EMAIL PROTECTED])
> wrote:
> > > > + if (unlikely(skb->emergency))
> > > > + current->flags |= PF_MEMALLOC;
> > >
> > > Access to 'current' in netif_receive_
On Tue, Jan 16, 2007 at 02:47:54PM +0100, Peter Zijlstra ([EMAIL PROTECTED])
wrote:
> > > + if (unlikely(skb->emergency))
> > > + current->flags |= PF_MEMALLOC;
> >
> > Access to 'current' in netif_receive_skb()???
> > Why do you want to work with, for example keventd?
>
> Can this run i
On Tue, 2007-01-16 at 16:25 +0300, Evgeniy Polyakov wrote:
> On Tue, Jan 16, 2007 at 10:46:06AM +0100, Peter Zijlstra ([EMAIL PROTECTED])
> wrote:
> > @@ -1767,10 +1767,23 @@ int netif_receive_skb(struct sk_buff *sk
> > struct net_device *orig_dev;
> > int ret = NET_RX_DROP;
> > __be1
On Tue, Jan 16, 2007 at 10:46:06AM +0100, Peter Zijlstra ([EMAIL PROTECTED])
wrote:
> In order to provide robust networked storage there must be a guarantee
> of progress. That is, the storage device must never stall because of
> (physical)
> OOM, because the device itself might be needed to get
These patches implement the basic infrastructure to allow swap over networked
storage.
The basic idea is to reserve some memory up front to use when regular memory
runs out.
To bound network behaviour we accept only a limited number of concurrent
packets and drop those packets that are not aimed
In order to provide robust networked storage there must be a guarantee
of progress. That is, the storage device must never stall because of (physical)
OOM, because the device itself might be needed to get out of it (reclaim).
This means that the device must always find enough memory to build/send
Oops, it seems I missed some chunks.
New patch attached.
---
Subject: net: vm deadlock avoidance core
In order to provide robust networked block devices there must be a guarantee
of progress. That is, the block device must never stall because of (physical)
OOM, because the device itself might be
From: Peter Zijlstra <[EMAIL PROTECTED]>
Date: Mon, 27 Nov 2006 15:06:25 +0100
> The patches definitely need more work but would you agree with the
> general direction I'm working in or would you suggest yet another
> direction?
You're definitely going to have to wait at least a week or so
before
Hi Dave,
I have a new version of these patches; I'm still using SOCK_VMIO socket
tagging and skb->emergency marks, since I have not come up with another
approach that might work and my RFC to netdev has so far been ignored.
Other than this though, it changed quite a bit;
- I now use the regular
On 9/12/06, Linus Torvalds <[EMAIL PROTECTED]> wrote:
On Tue, 12 Sep 2006, Peter Zijlstra wrote:
>
> Linus, when I mentioned swap over network to you in Ottawa, you said it was
> a valid use case, that people actually do and want this. Can you agree with
> the approach taken in these patches?
On Tue, 12 Sep 2006, Peter Zijlstra wrote:
>
> Linus, when I mentioned swap over network to you in Ottawa, you said it was
> a valid use case, that people actually do and want this. Can you agree with
> the approach taken in these patches?
Well, in all honesty, I don't think I really said "vali
--
Yet another instance of my networked swap patches.
The patch-set consists of four parts:
- patches 1-2; the basic 'framework' for deadlock avoidance
- patches 3-9; implement swap over NFS
- patches 10-13; implement swap over NBD
- patches 14-20; implement swap over iSCSI
The iSCSI work d
In order to provide robust networked block devices there must be a guarantee
of progress. That is, the block device must never stall because of (physical)
OOM, because the device itself might be needed to get out of it (reclaim).
This means that the device queue must always be unplugable, this in
In order to provide robust networked block devices there must be a guarantee
of progress. That is, the block device must never stall because of (physical)
OOM, because the device itself might be needed to get out of it (reclaim).
This means that the device queue must always be unplugable, this in
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
>> not
>> merge the code of
On Tue, 2006-08-29 at 02:01 +0200, Indan Zupancic wrote:
> On Mon, August 28, 2006 19:32, Peter Zijlstra said:
> > Ah, no accident there, I'm fully aware that there would need to be a
> > spinlock in adjust_memalloc_reserve() if there were another caller.
> > (I even had it there for some time) -
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, 2006-08-28 at 18:03 +0200, Indan Zupancic wrote:
> On Mon, August 28, 2006 12:22, Peter Zijlstra said:
> >> > @@ -391,6 +391,7 @@ enum sock_flags {
> >> > SOCK_RCVTSTAMP, /* %SO_TIMESTAMP setting */
> >> > SOCK_LOCALROUTE, /* route locally only, %SO_DONTROUTE setting */
>
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 Sat, 2006-08-26 at 04:37 +0200, Indan Zupancic wrote:
> On Fri, August 25, 2006 17:39, Peter Zijlstra said:
> > @@ -282,7 +282,8 @@ struct sk_buff {
> > nfctinfo:3;
> > __u8pkt_type:3,
> > fclone:2,
> > -
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;
> +
The core of the VM deadlock avoidance framework.
In order to provide robust networked block devices there must be a guarantee
of progress. That is, the block device must never stall because of OOM because
the device itself might be needed to get out of OOM (reclaim pageout).
This means that the
28 matches
Mail list logo
