Hi J.H.,
On Mon, 08 Jan 2007 23:25:18 -0800, J.H. wrote:
> On Tue, 2007-01-09 at 08:01 +0100, Jean Delvare wrote:
> > > they cache just fine and it's not that big of a deal, and there are much
> > > longer poles in the tent right now.
> >
> > The images are being regenerated every other minute or
On Tue, 2007-01-09 at 08:01 +0100, Jean Delvare wrote:
> Hi JH,
>
> On Mon, 08 Jan 2007 13:33:04 -0800, J.H. wrote:
> > On Mon, 2007-01-08 at 22:20 +0100, Jean Delvare wrote:
> > > * Drop the bandwidth graphs. Most visitors certainly do not care, and
> > > their presence generates traffic on all w
Hi JH,
On Mon, 08 Jan 2007 13:33:04 -0800, J.H. wrote:
> On Mon, 2007-01-08 at 22:20 +0100, Jean Delvare wrote:
> > * Drop the bandwidth graphs. Most visitors certainly do not care, and
> > their presence generates traffic on all web servers regardless of the
> > one the visitor is using, as each
Hi again.
On Tue, 2007-01-09 at 06:09 +0100, Adrian Bunk wrote:
> On Tue, Jan 09, 2007 at 03:29:35PM +1100, Nigel Cunningham wrote:
> > Hi again.
> >
> > On Sat, 2007-01-06 at 21:17 -0800, H. Peter Anvin wrote:
> > > Nigel Cunningham wrote:
> > > > On Tue, 2006-12-26 at 08:49 -0800, H. Peter Anvi
On Tue, Jan 09, 2007 at 03:29:35PM +1100, Nigel Cunningham wrote:
> Hi again.
>
> On Sat, 2007-01-06 at 21:17 -0800, H. Peter Anvin wrote:
> > Nigel Cunningham wrote:
> > > On Tue, 2006-12-26 at 08:49 -0800, H. Peter Anvin wrote:
> > >> The two things git users can do to help is:
> > >>
> > >> 1.
Hi again.
On Sat, 2007-01-06 at 21:17 -0800, H. Peter Anvin wrote:
> Nigel Cunningham wrote:
> > On Tue, 2006-12-26 at 08:49 -0800, H. Peter Anvin wrote:
> >> The two things git users can do to help is:
> >>
> >> 1. Make sure your alternatives file is set up correctly;
> >> 2. Keep your trees pack
Salut Willy,
On Mon, 8 Jan 2007 20:37:58 +0100, Willy Tarreau wrote:
> Hi Jean,
>
> On Mon, Jan 08, 2007 at 08:31:50PM +0100, Jean Delvare wrote:
> > Hi Peter,
> >
> > On Tue, 26 Dec 2006 09:02:59 -0800, H. Peter Anvin wrote:
> > > Willy Tarreau wrote:
> > >
> > > > Just evil suggestion, but if
On Mon, 2007-01-08 at 22:20 +0100, Jean Delvare wrote:
> Hi JH,
>
> On Sat, 16 Dec 2006 11:30:34 -0800, J.H. wrote:
> > The root cause boils down to with git, gitweb and the normal mirroring
> > on the frontend machines our basic working set no longer stays resident
> > in memory, which is forcing
Hi JH,
On Sat, 16 Dec 2006 11:30:34 -0800, J.H. wrote:
> The root cause boils down to with git, gitweb and the normal mirroring
> on the frontend machines our basic working set no longer stays resident
> in memory, which is forcing more and more to actively go to disk causing
> a much higher I/O l
On Sun, 17 Dec 2006 10:23:54 -0800, Randy Dunlap wrote:
> I can't really say since I have no performance/profile data to base
> it on. There has been some noise about (not) providing mirror services
> for distros. Is that a big cpu/memory consumer? If so, then is that
> something that kernel.org
Hi Jean,
On Mon, Jan 08, 2007 at 08:31:50PM +0100, Jean Delvare wrote:
> Hi Peter,
>
> On Tue, 26 Dec 2006 09:02:59 -0800, H. Peter Anvin wrote:
> > Willy Tarreau wrote:
> >
> > > Just evil suggestion, but if you contact someone else than HP, they
> > > might be _very_ interested in taking HP's p
Hi Peter,
On Tue, 26 Dec 2006 09:02:59 -0800, H. Peter Anvin wrote:
> Willy Tarreau wrote:
>
> > Just evil suggestion, but if you contact someone else than HP, they
> > might be _very_ interested in taking HP's place and providing whatever
> > you need to get their name on www.kernel.org. Sun and
Randy Dunlap wrote:
Hi,
I'm sure that all of this ext3fs etc. discussion is good,
but let me clarify: I would be much happier if the kernel.org
main page and the finger_banner info were updated at the same
time that new tarballs were put onto kernel.org.
Tough sh*t.
Now someone may say th
Greg KH wrote:
Well, I create my repos by doing a:
git clone -l --bare
which makes a hardlink from Linus's tree.
But then it gets copied over to the public server, which probably severs
that hardlink :(
Any shortcut to clone or set up a repo using "alternatives" so that we
don't have
On Sat, Jan 06, 2007 at 11:22:31PM -0500, Jeff Garzik wrote:
> >On Tue, 2006-12-26 at 08:49 -0800, H. Peter Anvin wrote:
> >>Not really. In fact, it would hardly help at all.
> >>
> >>The two things git users can do to help is:
> >>
> >>1. Make sure your alternatives file is set up correctly;
> >>
On Sat, 06 Jan 2007 11:21:15 -0800 J.H. wrote:
> It's an issue of load, and both machines are running 'hot' so to speak.
> When the loads on the machines climbs our update rsyncs take longer to
> complete (considering that our loads are completely based on I/O this
> isn't surprising). More or le
Nigel Cunningham wrote:
Hi.
On Tue, 2006-12-26 at 08:49 -0800, H. Peter Anvin wrote:
Nigel Cunningham wrote:
Hi.
I've have git trees against a few versions besides Linus', and have just
moved all but Linus' to staging to help until you can get your new
hardware. If others were encouraged to d
Hi.
On Sat, 2007-01-06 at 23:10 -0500, Jeff Garzik wrote:
> Nigel Cunningham wrote:
> > Hi.
> >
> > On Tue, 2006-12-26 at 08:49 -0800, H. Peter Anvin wrote:
> >> Nigel Cunningham wrote:
> >>> Hi.
> >>>
> >>> I've have git trees against a few versions besides Linus', and have just
> >>> moved all
On Sat, 6 Jan 2007, Jeff Garzik wrote:
>
> Also, I wonder if "git push" will push only the non-linux-2.6.git objects, if
> both local and remote sides have the proper alternatives set up?
Yes.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
th
On Tue, 2006-12-26 at 08:49 -0800, H. Peter Anvin wrote:
Not really. In fact, it would hardly help at all.
The two things git users can do to help is:
1. Make sure your alternatives file is set up correctly;
2. Keep your trees packed and pruned, to keep the file count down.
If you do this, th
Nigel Cunningham wrote:
Hi.
On Tue, 2006-12-26 at 08:49 -0800, H. Peter Anvin wrote:
Nigel Cunningham wrote:
Hi.
I've have git trees against a few versions besides Linus', and have just
moved all but Linus' to staging to help until you can get your new
hardware. If others were encouraged to d
Hi.
On Tue, 2006-12-26 at 08:49 -0800, H. Peter Anvin wrote:
> Nigel Cunningham wrote:
> > Hi.
> >
> > I've have git trees against a few versions besides Linus', and have just
> > moved all but Linus' to staging to help until you can get your new
> > hardware. If others were encouraged to do the
Andrew Morton wrote:
The most fundamental problem seems to be that I can't tell currnt Linux
kernels that the dcache/icache is precious, and that it's way too eager
to dump dcache and icache in favour of data blocks. If I could do that,
this problem would be much, much smaller.
Usually peo
On Sat, 06 Jan 2007 12:20:27 -0800
"H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> >>
> >> Unfortunately that affects all three of: dcache, icache, and mbcache.
> >> Maybe we could split that sysctl in two (Andrew?), so that one sysctl
> >> affects dcache/icache and another
Andrew Morton wrote:
Unfortunately that affects all three of: dcache, icache, and mbcache.
Maybe we could split that sysctl in two (Andrew?), so that one sysctl
affects dcache/icache and another affects mbcache.
That would be simple enough to do, if someone can demonstrate a
need.
Is th
Andrew Morton wrote:
The most fundamental problem seems to be that I can't tell currnt Linux
kernels that the dcache/icache is precious, and that it's way too eager
to dump dcache and icache in favour of data blocks. If I could do that,
this problem would be much, much smaller.
Usually peo
On Sat, 06 Jan 2007 15:13:50 -0500
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> H. Peter Anvin wrote:
> > Randy Dunlap wrote:
> >>
> BTW, yesterday my 2.4 patches were not published, but I noticed that
> they were not even signed not bziped on hera. At first I simply thought
> it was re
On Sat, 06 Jan 2007 11:37:46 -0800
Nicholas Miell <[EMAIL PROTECTED]> wrote:
> On Sat, 2007-01-06 at 11:18 -0800, H. Peter Anvin wrote:
> > Randy Dunlap wrote:
> > >
> > >>> BTW, yesterday my 2.4 patches were not published, but I noticed that
> > >>> they were not even signed not bziped on hera. A
H. Peter Anvin wrote:
Randy Dunlap wrote:
BTW, yesterday my 2.4 patches were not published, but I noticed that
they were not even signed not bziped on hera. At first I simply thought
it was related, but right now I have a doubt. Maybe the automatic
script
has been temporarily been disabled o
On Sat, 2007-01-06 at 11:18 -0800, H. Peter Anvin wrote:
> Randy Dunlap wrote:
> >
> >>> BTW, yesterday my 2.4 patches were not published, but I noticed that
> >>> they were not even signed not bziped on hera. At first I simply thought
> >>> it was related, but right now I have a doubt. Maybe the a
On Sat, Jan 06, 2007 at 11:18:37AM -0800, H. Peter Anvin wrote:
> Randy Dunlap wrote:
> >
> >>>BTW, yesterday my 2.4 patches were not published, but I noticed that
> >>>they were not even signed not bziped on hera. At first I simply thought
> >>>it was related, but right now I have a doubt. Maybe t
It's an issue of load, and both machines are running 'hot' so to speak.
When the loads on the machines climbs our update rsyncs take longer to
complete (considering that our loads are completely based on I/O this
isn't surprising). More or less nothing has changed since:
http://lkml.org/lkml/2006/
Randy Dunlap wrote:
BTW, yesterday my 2.4 patches were not published, but I noticed that
they were not even signed not bziped on hera. At first I simply thought
it was related, but right now I have a doubt. Maybe the automatic script
has been temporarily been disabled on hera too ?
The script
On Mon, 18 Dec 2006 22:52:51 -0800 J.H. wrote:
> On Tue, 2006-12-19 at 07:34 +0100, Willy Tarreau wrote:
> > On Sat, Dec 16, 2006 at 11:30:34AM -0800, J.H. wrote:
> > (...)
> >
> > > So we know the problem is there, and we are working on it - we are
> > > getting e-mails about it if not daily tha
Willy Tarreau wrote:
Just evil suggestion, but if you contact someone else than HP, they
might be _very_ interested in taking HP's place and providing whatever
you need to get their name on www.kernel.org. Sun and IBM do such
monter machines too. That would not be very kind to HP, but it might
h
Nigel Cunningham wrote:
Hi.
I've have git trees against a few versions besides Linus', and have just
moved all but Linus' to staging to help until you can get your new
hardware. If others were encouraged to do the same, it might help a lot?
Not really. In fact, it would hardly help at all.
Russell King wrote:
Ergo, downloads via http from ftp.uk.kernel.org are at best unreliable
for multiple requests.
I agree that it's not directly your problem, and isn't something you
have direct control over. However, if you want to round-robin the
.kernel.org IP addresses between different pr
Dave Jones wrote:
A wild idea just occured to me. You guys are running Fedora/RHEL kernels
on the kernel.org boxes iirc, which have Ingo's 'tux' httpd accelerator.
It might not make the problem go away, but it could make it more
bearable under high load. Or it might do absolutely squat depend
On Sat, 16 Dec 2006, J.H. wrote:
> - Gitweb is causing us no end of headache,
Is there any mirror for http://git.kernel.org/git/ other than
git2.kernel.org? If there is, it would probably help to make it better
known.
thanks,
Tim
-
To unsubscribe from this list: send the line "unsubscribe linu
On Tue, Dec 19, 2006 at 09:36:06AM -0500, Dave Jones wrote:
> On Mon, Dec 18, 2006 at 11:39:51PM -0800, J.H. wrote:
>
> > I'll have to look into it - but by and large the round robining tends to
> > work. Specifically as I am writing this the machines are both pushing
> > right around 150mbps,
On Mon, Dec 18, 2006 at 11:39:51PM -0800, J.H. wrote:
> I'll have to look into it - but by and large the round robining tends to
> work. Specifically as I am writing this the machines are both pushing
> right around 150mbps, however the load on zeus1 is 170 vs. zeus2's 4.
> Also when we peak
On Mon, Dec 18, 2006 at 11:39:51PM -0800, J.H. wrote:
> > If the frontend machines are not taken off-line too often, it should
> > be no big deal for them to handle something such as LVS, and would
> > help spreding the load.
>
> I'll have to look into it - but by and large the round robining tend
On Tue, 2006-12-19 at 07:46 +0100, Willy Tarreau wrote:
> On Sun, Dec 17, 2006 at 04:42:56PM -0800, J.H. wrote:
> > On Mon, 2006-12-18 at 00:37 +0200, Matti Aarnio wrote:
> > > On Sun, Dec 17, 2006 at 10:23:54AM -0800, Randy Dunlap wrote:
> > > > J.H. wrote:
> > > ...
> > > > >The root cause boils
On Tue, 2006-12-19 at 07:34 +0100, Willy Tarreau wrote:
> On Sat, Dec 16, 2006 at 11:30:34AM -0800, J.H. wrote:
> (...)
> > Since it's apparent not everyone is aware of what we are doing, I'll
> > mention briefly some of the bigger points.
> >
> > - We have contacted HP to see if we can get additi
On Sun, Dec 17, 2006 at 04:42:56PM -0800, J.H. wrote:
> On Mon, 2006-12-18 at 00:37 +0200, Matti Aarnio wrote:
> > On Sun, Dec 17, 2006 at 10:23:54AM -0800, Randy Dunlap wrote:
> > > J.H. wrote:
> > ...
> > > >The root cause boils down to with git, gitweb and the normal mirroring
> > > >on the fron
On Sat, Dec 16, 2006 at 11:30:34AM -0800, J.H. wrote:
(...)
> Since it's apparent not everyone is aware of what we are doing, I'll
> mention briefly some of the bigger points.
>
> - We have contacted HP to see if we can get additional hardware, mind
> you though this is a long term solution and wi
On Mon, 2006-12-18 at 00:37 +0200, Matti Aarnio wrote:
> On Sun, Dec 17, 2006 at 10:23:54AM -0800, Randy Dunlap wrote:
> > J.H. wrote:
> ...
> > >The root cause boils down to with git, gitweb and the normal mirroring
> > >on the frontend machines our basic working set no longer stays resident
> > >
On Sun, Dec 17, 2006 at 10:23:54AM -0800, Randy Dunlap wrote:
> J.H. wrote:
...
> >The root cause boils down to with git, gitweb and the normal mirroring
> >on the frontend machines our basic working set no longer stays resident
> >in memory, which is forcing more and more to actively go to disk ca
J.H. wrote:
The problem has been hashed over quite a bit recently, and I would be
curious what you would consider the real problem after you see the
situation.
OK, thanks for the summary.
The root cause boils down to with git, gitweb and the normal mirroring
on the frontend machines our basic
Pavel Machek wrote:
Would you accept help from someone else than HP? kernel.org is very
important, and hardware is cheap these days... What are the
requirements for machine to be interesting to kernel.org? I guess
AMD/1GHz, 1GB ram, 100GB disk is not interesting to you
quoting http://www.ke
Hi!
> The problem has been hashed over quite a bit recently, and I would be
> curious what you would consider the real problem after you see the
> situation.
>
> The root cause boils down to with git, gitweb and the normal mirroring
> on the frontend machines our basic working set no longer stays
Hi.
I've have git trees against a few versions besides Linus', and have just
moved all but Linus' to staging to help until you can get your new
hardware. If others were encouraged to do the same, it might help a lot?
Regards,
Nigel
-
To unsubscribe from this list: send the line "unsubscribe lin
On Sat, Dec 16, 2006 at 11:30:34AM -0800, J.H. wrote:
> The problem has been hashed over quite a bit recently, and I would be
> curious what you would consider the real problem after you see the
> situation.
One thing which isn't helping you is the way folk inevitably end up
using ftp.kernel.org r
The problem has been hashed over quite a bit recently, and I would be
curious what you would consider the real problem after you see the
situation.
The root cause boils down to with git, gitweb and the normal mirroring
on the frontend machines our basic working set no longer stays resident
in memo
Andrew Morton wrote:
On Sat, 16 Dec 2006 09:44:21 -0800
Randy Dunlap <[EMAIL PROTECTED]> wrote:
On Thu, 14 Dec 2006 23:37:18 +0100 Pavel Machek wrote:
Hi!
[EMAIL PROTECTED]:/data/pavel$ finger @www.kernel.org
[zeus-pub.kernel.org]
...
The latest -mm patch to the stable Linux kernels is: 2.6.
On Sat, 16 Dec 2006 09:44:21 -0800
Randy Dunlap <[EMAIL PROTECTED]> wrote:
> On Thu, 14 Dec 2006 23:37:18 +0100 Pavel Machek wrote:
>
> > Hi!
> >
> > [EMAIL PROTECTED]:/data/pavel$ finger @www.kernel.org
> > [zeus-pub.kernel.org]
> > ...
> > The latest -mm patch to the stable Linux kernels is: 2
On Thu, 14 Dec 2006 23:37:18 +0100 Pavel Machek wrote:
> Hi!
>
> [EMAIL PROTECTED]:/data/pavel$ finger @www.kernel.org
> [zeus-pub.kernel.org]
> ...
> The latest -mm patch to the stable Linux kernels is: 2.6.19-rc6-mm2
> [EMAIL PROTECTED]:/data/pavel$ head /data/l/linux-mm/Makefile
> VERSION = 2
57 matches
Mail list logo