On 3/5/19 7:44 PM, Eric Dumazet wrote:
> On Tue, Mar 5, 2019 at 7:11 AM Eric Dumazet wrote:
>>> My original suggestion was to use VM_WARN_ONCE() so that the debug checks
>>> would
>>> be compiled out by the compiler, unless you compile a debug kernel.
>>>
>>> Something like :
>>>
>>> diff --gi
On Tue, Mar 5, 2019 at 7:11 AM Eric Dumazet wrote:
>
> >
> > My original suggestion was to use VM_WARN_ONCE() so that the debug checks
> > would
> > be compiled out by the compiler, unless you compile a debug kernel.
> >
> > Something like :
> >
> > diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
>
Resent in plain text mode for the lists.
On Tue, Mar 5, 2019 at 7:08 AM Eric Dumazet wrote:
>
>
>
> On Tue, Mar 5, 2019 at 6:24 AM Vasily Averin wrote:
>>
>> On 3/4/19 6:51 PM, Eric Dumazet wrote:
>> > On 03/04/2019 04:58 AM, Vasily Averin wrote:
>> >> Eric, what do you think about following pat
On 3/4/19 6:51 PM, Eric Dumazet wrote:
> On 03/04/2019 04:58 AM, Vasily Averin wrote:
>> Eric, what do you think about following patch?
>> I validate its backported version on RHEL7 based OpenVZ kernel before
>> sending to mainline.
>>
>> diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
>> index cf3c
On 03/04/2019 04:58 AM, Vasily Averin wrote:
> On 2/21/19 7:00 PM, Eric Dumazet wrote:
>> On Thu, Feb 21, 2019 at 7:30 AM Vasily Averin wrote:
>>>
>>> There was few incidents when XFS over network block device generates
>>> IO requests with slab-based metadata. If these requests are processed
>
On 2/21/19 7:00 PM, Eric Dumazet wrote:
> On Thu, Feb 21, 2019 at 7:30 AM Vasily Averin wrote:
>>
>> There was few incidents when XFS over network block device generates
>> IO requests with slab-based metadata. If these requests are processed
>> via sendpage path tcp_sendpage() calls skb_can_coale
On 2/25/19 12:15 PM, Vasily Averin wrote:
> On 2/22/19 7:39 PM, Eric Dumazet wrote:
>> On Fri, Feb 22, 2019 at 6:02 AM Vasily Averin wrote:
>
>>> Eric, could you please elaborate once again why tcp_sendpage() should not
>>> handle slab objects?
>>
>> Simply because SLAB has its own way to manage
On 2/22/19 7:39 PM, Eric Dumazet wrote:
> On Fri, Feb 22, 2019 at 6:02 AM Vasily Averin wrote:
>> Eric, could you please elaborate once again why tcp_sendpage() should not
>> handle slab objects?
>
> Simply because SLAB has its own way to manage objects from a page, and
> does not care
> about
On Fri, Feb 22, 2019 at 6:02 AM Vasily Averin wrote:
>
> On 2/21/19 7:00 PM, Eric Dumazet wrote:
> > On Thu, Feb 21, 2019 at 7:30 AM Vasily Averin wrote:
> >> index 2079145a3b7c..cf9572f4fc0f 100644
> >> --- a/net/ipv4/tcp.c
> >> +++ b/net/ipv4/tcp.c
> >> @@ -996,6 +996,7 @@ ssize_t do_tcp_sendpa
On 2/21/19 7:00 PM, Eric Dumazet wrote:
> On Thu, Feb 21, 2019 at 7:30 AM Vasily Averin wrote:
>> index 2079145a3b7c..cf9572f4fc0f 100644
>> --- a/net/ipv4/tcp.c
>> +++ b/net/ipv4/tcp.c
>> @@ -996,6 +996,7 @@ ssize_t do_tcp_sendpages(struct sock *sk, struct page
>> *page, int offset,
>>
On Thu, Feb 21, 2019 at 7:30 AM Vasily Averin wrote:
>
> There was few incidents when XFS over network block device generates
> IO requests with slab-based metadata. If these requests are processed
> via sendpage path tcp_sendpage() calls skb_can_coalesce() and merges
> neighbour slab objects into
There was few incidents when XFS over network block device generates
IO requests with slab-based metadata. If these requests are processed
via sendpage path tcp_sendpage() calls skb_can_coalesce() and merges
neighbour slab objects into one skb fragment.
If receiving side is located on the same hos
12 matches
Mail list logo
