YOSHIFUJI Hideaki / 吉藤英明 wrote:
+ .data = &sysctl_tcp_rto_max,
+ .maxlen = sizeof(unsigned),
sizeof(unsigned long)
Good catch. That would have corrupted things badly on some 64b
platforms. With all the flux in the area I forgot to change the size
In article <[EMAIL PROTECTED]> (at Wed, 11 Oct 2006 17:51:24 -0700), Ben
Woodard <[EMAIL PROTECTED]> says:
> diff -ru linux-2.6.18/net/ipv4/sysctl_net_ipv4.c
> linux-2.6.18.new/net/ipv4/sysctl_net_ipv4.c
> --- linux-2.6.18/net/ipv4/sysctl_net_ipv4.c 2006-09-19 20:42:06.0
> -0700
> +++
Here we go again. The changes are as follows:
1) the spaces are gone and now it is tabs.
2) used msecs_to_jiffies() and jiffies_to_msecs(). I'm much happier with
that. I didn't know those functions existed.
3) changed over to proc_doulongvec_ms_jiffies_minmax(). Last night's
test compile failed
Ben Woodard wrote:
> diff -ru linux-2.6.18/include/net/tcp.h linux-2.6.18.new/include/net/tcp.h
> --- linux-2.6.18/include/net/tcp.h2006-09-19 20:42:06.0 -0700
> +++ linux-2.6.18.new/include/net/tcp.h2006-
Actually, your entire patch uses spaces for indentation
of every new line added, not just those two new struct members
I pointed out. Please use tabs for all of those cases.
Thanks a lot.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTE
From: Ben Woodard <[EMAIL PROTECTED]>
Date: Tue, 10 Oct 2006 18:46:58 -0700
> @@ -257,6 +259,8 @@
> __u8frto_counter; /* Number of new acks after RTO */
> __u8nonagle;/* Disable Nagle algorithm? */
> __u8keepalive_probes; /* num of allowed keep a
In article <[EMAIL PROTECTED]> (at Tue, 10 Oct 2006 18:46:58 -0700), Ben
Woodard <[EMAIL PROTECTED]> says:
> diff -ru linux-2.6.18/net/ipv4/tcp.c linux-2.6.18.new/net/ipv4/tcp.c
> --- linux-2.6.18/net/ipv4/tcp.c 2006-09-19 20:42:06.0 -0700
> +++ linux-2.6.18.new/net/ipv4/tcp.c 200
David Miller wrote:
From: Ben Woodard <[EMAIL PROTECTED]>
Date: Tue, 03 Oct 2006 11:14:38 -0700
Other issues:
1) 2 "u32" in the tcp_sock is a lot of space to devote to this
new state. If it can fit in 2 "u16"'s or even less space,
please use that.
2) the expression "(tp->foo ? : sysctl
On Wed, 04 Oct 2006 00:07:22 -0700 (PDT)
David Miller <[EMAIL PROTECTED]> wrote:
> From: Ben Woodard <[EMAIL PROTECTED]>
> Date: Tue, 03 Oct 2006 11:14:38 -0700
>
> > > Other issues:
> > >
> > > 1) 2 "u32" in the tcp_sock is a lot of space to devote to this
> > >new state. If it can fit in
From: Ingo Oeser <[EMAIL PROTECTED]>
Date: Wed, 4 Oct 2006 10:56:12 +0200
> David Miller wrote:
> > At the very least, seconds might not be fine enough granularity
> > for some circumstances. Heck, the default RTO_MIN is 1/5 of a
> > second. :-)
> >
> > I also understand that going to millisecon
David Miller wrote:
> At the very least, seconds might not be fine enough granularity
> for some circumstances. Heck, the default RTO_MIN is 1/5 of a
> second. :-)
>
> I also understand that going to milliseconds or microseconds would
> make the size of the in-socket struct members an issue again
From: Ben Woodard <[EMAIL PROTECTED]>
Date: Tue, 03 Oct 2006 11:14:38 -0700
> > Other issues:
> >
> > 1) 2 "u32" in the tcp_sock is a lot of space to devote to this
> >new state. If it can fit in 2 "u16"'s or even less space,
> >please use that.
> >
> > 2) the expression "(tp->foo ? : s
David Miller wrote:
From: Ben Woodard <[EMAIL PROTECTED]>
Date: Wed, 27 Sep 2006 11:52:57 -0700
Because these are general utility clusters we run many different
programs and so trying to fix this problem in the application is not
possible since there are literally hundreds if not thousands of
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Wed, 27 Sep 2006 16:00:44 -0700
> On Wed, 27 Sep 2006 16:16:38 -0700 (PDT)
> David Miller <[EMAIL PROTECTED]> wrote:
>
> > From: Ben Woodard <[EMAIL PROTECTED]>
> > Date: Wed, 27 Sep 2006 11:52:57 -0700
> >
> > > Because these are general utility
On Wed, 27 Sep 2006 16:16:38 -0700 (PDT)
David Miller <[EMAIL PROTECTED]> wrote:
> From: Ben Woodard <[EMAIL PROTECTED]>
> Date: Wed, 27 Sep 2006 11:52:57 -0700
>
> > Because these are general utility clusters we run many different
> > programs and so trying to fix this problem in the applicatio
From: Ben Woodard <[EMAIL PROTECTED]>
Date: Wed, 27 Sep 2006 11:52:57 -0700
> Because these are general utility clusters we run many different
> programs and so trying to fix this problem in the application is not
> possible since there are literally hundreds if not thousands of them.
Then why
Here at LLNL we have a rather challenging network environment on our
clusters. We basically have 1000's of gigE links attached to an
oversubscribed federated network. Most of the time this network is idle
but the expected workload is for regular spikes extremely heavy activity
lasting a few min
17 matches
Mail list logo
