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 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
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
9 matches
Mail list logo
