All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Wang <jasowang@redhat.com>
To: monstr@monstr.eu
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
	netdev@vger.kernel.org,
	John Williams <john.williams@petalogix.com>,
	David Miller <davem@davemloft.net>,
	Glauber Costa <glommer@parallels.com>
Subject: Re: [PATCH] tcp: restore correct limit
Date: Tue, 10 Apr 2012 18:29:45 +0800	[thread overview]
Message-ID: <4F840B99.8040409@redhat.com> (raw)
In-Reply-To: <4F8407F7.8070703@monstr.eu>

On 04/10/2012 06:14 PM, Michal Simek wrote:
> On 04/10/2012 12:03 PM, Eric Dumazet wrote:
>> Commit c43b874d5d714f (tcp: properly initialize tcp memory limits)
>> added a regression on machines with low amount of memory, since sockets
>> cant use 1/128 of memory but 1/1024
>>
>> Fix this to match comment and previous behavior.
>>
>> Signed-off-by: Eric Dumazet<eric.dumazet@gmail.com>
>> Cc: Jason Wang<jasowang@redhat.com>
>> Cc: Glauber Costa<glommer@parallels.com>
>> ---
>>   net/ipv4/tcp.c |    2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
>> index 5d54ed3..67d726e 100644
>> --- a/net/ipv4/tcp.c
>> +++ b/net/ipv4/tcp.c
>> @@ -3302,7 +3302,7 @@ void __init tcp_init(void)
>>
>>       tcp_init_mem(&init_net);
>>       /* Set per-socket limits to no more than 1/128 the pressure 
>> threshold */
>> -    limit = nr_free_buffer_pages()<<  (PAGE_SHIFT - 10);
>> +    limit = nr_free_buffer_pages()<<  (PAGE_SHIFT - 7);
>>       limit = max(limit, 128UL);
>>       max_share = min(4UL*1024*1024, limit);
>>
>
> hw design with csum is also much better.
> Tested-by: Michal Simek <monstr@monstr.eu>
>
> Thanks for help,
> Michal
>
>
>
>
>
Hi Michal and Eric:

Which version of kernel did you test, did you try the newest kernel? The 
reason I use (PAGE_SHIFT - 10) is in the commit before 3dc43e3, the 
limit were calculated with:

     limit = nr_free_buffer_pages() / 8;
     limit = max(limit, 128UL);
...
     limit = ((unsigned long)sysctl_tcp_mem[1]) << (PAGE_SHIFT - 7);

So the rmem should be ok. But there's a defect (which I think does 
affect the regression) of my patch would could cause limit that we 
should shift after comparing with 128UL like:

     limit = nr_free_buffer_pages() / 8;
     limit = max(limit, 128UL) << (PAGE_SHIFT - 7);

Is anything I miss?

Thanks

  reply	other threads:[~2012-04-10 10:29 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-10  8:10 net: more accurate skb truesize - regression on Microblaze Michal Simek
2012-04-10  8:27 ` Eric Dumazet
2012-04-10  8:32   ` Eric Dumazet
2012-04-10  8:37     ` Michal Simek
2012-04-10  8:45       ` Eric Dumazet
2012-04-10  9:11         ` Michal Simek
2012-04-10  9:24           ` Eric Dumazet
2012-04-10  9:29             ` Michal Simek
2012-04-10  9:38               ` Eric Dumazet
2012-04-10  9:50                 ` Michal Simek
2012-04-10  9:52                 ` Eric Dumazet
2012-04-10 10:03                   ` Michal Simek
2012-04-10 10:03                 ` [PATCH] tcp: restore correct limit Eric Dumazet
2012-04-10 10:14                   ` Michal Simek
2012-04-10 10:29                     ` Jason Wang [this message]
2012-04-10 10:32                       ` Michal Simek
2012-04-10 10:40                       ` Eric Dumazet
2012-04-10 10:56                         ` [PATCH v2] " Eric Dumazet
2012-04-10 18:42                           ` David Miller
2012-04-10 11:32       ` net: more accurate skb truesize - regression on Microblaze Eric Dumazet
2012-04-10 11:38         ` Michal Simek
2012-04-10 11:50           ` Eric Dumazet
2012-04-10 12:12             ` Michal Simek
2012-04-10 13:43           ` David Miller
     [not found]             ` <CAHTX3dLRR09_QaA2BzmbCVAUVVGvr_P3s2d1KEgPLMYGGVzrpA@mail.gmail.com>
2012-04-10 13:52               ` David Miller
     [not found]                 ` <CAHTX3dLz9+A48u6ckGiDytBkyMrvgV0Zi3xfnt4RBmoagJbndA@mail.gmail.com>
2012-04-10 14:14                   ` David Miller
2012-04-10 14:38                     ` Michal Simek
2012-04-10  8:36   ` Michal Simek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F840B99.8040409@redhat.com \
    --to=jasowang@redhat.com \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=glommer@parallels.com \
    --cc=john.williams@petalogix.com \
    --cc=monstr@monstr.eu \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.