RE: tcp stack tuning and Checkpoint FW1 & Legato Networker
> > I want to set the tcp_keepalive timer to 60 seconds and understand > possible implications for Linux. echo 60 >/proc/sys/net/ipv4/tcp_keepalive_time - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: >128 MB RAM stability problems (again)
> > Nobody has answered a basic concern: > Why does Win2k work while Linux does not? The answer could be as simple as the fact that Linux might be trying to write to the exact memory location that is bad but Win2k has not. It might also be that he in fact DOES have problems with win2k but is unaware of it, that location might be used for data storage rather than program execution. All I can say is this ... I have never used Windows on our production web farms and Linux 2.4 appears to work just fine will many different sizes of memory ... all greater than 128MB. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: >128 MB RAM stability problems (again)
> From: Alessandro Motter Ren [mailto:[EMAIL PROTECTED]] > > > Which filesystem are you using on this machine? > []s. > ext2fs on the production farm but I also have a pair of machines (SMB P-III 800) using reiserfs on mail spools. That pair of machines is not particularly busy, though. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: >128 MB RAM stability problems (again)
> I'm kind of astounded now, WHY can't linux-2.4.x run on ANY machine in > my house with more than 128 MB RAM?!? Can someone please point out to me > that he's actually running kernel-2.4.x on a machine with more than 128 > MB RAM and that he's NOT having severe stability problems? Running 2.4.6-pre and 2.4.6 proper on several machines. Quite busy and all have 256 to 512MB of RAM. As I type this, I am in the process of converting an entire production server farm over to 2.4.6 from 2.2.19 as the 2.4.6-pre series proved out well on a test machine in that farm. No stability problems at all. The only reboots were for patching up the kernel to the next -pre revision on that test box. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 128 MB RAM stability problems (again)
I'm kind of astounded now, WHY can't linux-2.4.x run on ANY machine in my house with more than 128 MB RAM?!? Can someone please point out to me that he's actually running kernel-2.4.x on a machine with more than 128 MB RAM and that he's NOT having severe stability problems? Running 2.4.6-pre and 2.4.6 proper on several machines. Quite busy and all have 256 to 512MB of RAM. As I type this, I am in the process of converting an entire production server farm over to 2.4.6 from 2.2.19 as the 2.4.6-pre series proved out well on a test machine in that farm. No stability problems at all. The only reboots were for patching up the kernel to the next -pre revision on that test box. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 128 MB RAM stability problems (again)
From: Alessandro Motter Ren [mailto:[EMAIL PROTECTED]] Which filesystem are you using on this machine? []s. ext2fs on the production farm but I also have a pair of machines (SMB P-III 800) using reiserfs on mail spools. That pair of machines is not particularly busy, though. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 128 MB RAM stability problems (again)
Nobody has answered a basic concern: Why does Win2k work while Linux does not? The answer could be as simple as the fact that Linux might be trying to write to the exact memory location that is bad but Win2k has not. It might also be that he in fact DOES have problems with win2k but is unaware of it, that location might be used for data storage rather than program execution. All I can say is this ... I have never used Windows on our production web farms and Linux 2.4 appears to work just fine will many different sizes of memory ... all greater than 128MB. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: tcp stack tuning and Checkpoint FW1 Legato Networker
I want to set the tcp_keepalive timer to 60 seconds and understand possible implications for Linux. echo 60 /proc/sys/net/ipv4/tcp_keepalive_time - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: The Joy of Forking
> YHBT. Evidently so. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: The Joy of Forking
> no SMP > x86 only (and similar, e.g. Crusoe) Never - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: The Joy of Forking
no SMP x86 only (and similar, e.g. Crusoe) Never - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: The Joy of Forking
YHBT. Evidently so. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] 2.4.6-pre2 page_launder() improvements
I ran some more tests yesterday with a little more RAM than last time and Rik's kernel performed much better than the vanilla kernel in the face of memory pressure when it was very busy. I could get both kernels into situations where they were unresponsive but these periods of time were much shorter with Rik's than with vanilla 2.4.6-pre2. A background kernel compile completed much faster on Rik's version on a fairly busy web server with 128MB of RAM. I goofed and forwarded the vmstat logs to the linux-mm mailing list so there is a huge message there with my results :-/ but I can forward them to anyone interested. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] 2.4.6-pre2 page_launder() improvements
I ran some more tests yesterday with a little more RAM than last time and Rik's kernel performed much better than the vanilla kernel in the face of memory pressure when it was very busy. I could get both kernels into situations where they were unresponsive but these periods of time were much shorter with Rik's than with vanilla 2.4.6-pre2. A background kernel compile completed much faster on Rik's version on a fairly busy web server with 128MB of RAM. I goofed and forwarded the vmstat logs to the linux-mm mailing list so there is a huge message there with my results :-/ but I can forward them to anyone interested. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] 2.4.6-pre2 page_launder() improvements
Ok, new test. Apache, no keepalives. 85 requests/sec for a 10K file 128MB of RAM Processor is UP 700MHz Intel vanilla 2.4.6-pre2 After everything settles down I have about 230-250 apache process running. about 4% of CPU in user and roughly 6% in system. Top shows: 18:12:47 up 59 min, 2 users, load average: 1.36, 3.26, 12.76 <- from a previous test, 240 processes: 239 sleeping, 1 running, 0 zombie, 0 stopped CPU states: 3.7% user, 6.8% system, 0.0% nice, 89.5% idle Mem:127184K total,95308K used,31876K free,14300K buffers Swap: 498004K total, 5032K used, 492972K free,14244K cached I have about 5MB in swap. Now kick off make -j8 in the linux kernel tree. CPU goes to about 80/20 user/system Top looks like this: 18:21:46 up 1:08, 2 users, load average: 17.71, 12.19, 12.55 299 processes: 290 sleeping, 9 running, 0 zombie, 0 stopped CPU states: 77.4% user, 22.6% system, 0.0% nice, 0.0% idle Mem:127184K total, 124664K used, 2520K free, 2644K buffers Swap: 498004K total,20160K used, 477844K free,11612K cached So I have pushed about 20M into swap with a really busy system (SCSI ext2) I run make -j8 in the source tree and am able to get the machine in a state where it is no longer interactive at the terminal, it seems to be hung, the make is generating nothing, top is not refreshing, machine responds to pings fine. Last top refresh shows: 18:26:41 up 1:13, 3 users, load average: 39.39, 19.70, 14.99 393 processes: 383 sleeping, 10 running, 0 zombie, 0 stopped CPU states: 39.6% user, 35.7% system, 0.0% nice, 24.7% idle Mem:127184K total, 123244K used, 3940K free, 2880K buffers Swap: 498004K total,34504K used, 463500K free,26332K cached I wait about 5 mintes to be sure I am not going to get anything back any time soon. Send cntl-c to the make, it takes abot a minute to quit. top starts refreshing and looks like this: 18:31:55 up 1:19, 3 users, load average: 228.76, 167.10, 80.71 331 processes: 330 sleeping, 1 running, 0 zombie, 0 stopped CPU states: 1.3% user, 27.7% system, 0.0% nice, 71.0% idle Mem:127184K total,87804K used,39380K free, 3184K buffers Swap: 498004K total,31776K used, 466228K free,24856K cached If I try again to run the make -j8 I can not seem to get it to "hang" again. Figuring it now has something cached that it can get to, I move to a different source tree and run another make -j and it hangs again in a different spot but with the same symptoms. So much for vanilla 2.4.6-pre2. I shut down and reboot into 2.4.6-pre2+Rik's patch. After everything settles down top shows: 19:07:32 up 12 min, 2 users, load average: 0.08, 0.05, 0.00 300 processes: 297 sleeping, 1 running, 2 zombie, 0 stopped CPU states: 5.3% user, 6.7% system, 0.0% nice, 88.0% idle Mem:127028K total, 106788K used,20240K free, 1144K buffers Swap: 498004K total,0K used, 498004K free,27408K cached Hmmm, not in swap at all. Ok ... now lets kick off a make -j8 CPU goes to 85/15 user/system about a 5% difference from the vanilla kernel. About 20MB into swap and the compile is progressing well. Compile finishes with no hangup top looks like: 19:13:19 up 18 min, 2 users, load average: 2.80, 3.89, 1.85 259 processes: 258 sleeping, 1 running, 0 zombie, 0 stopped CPU states: 3.7% user, 6.3% system, 0.0% nice, 90.0% idle Mem:127028K total,87368K used,39660K free, 1276K buffers Swap: 498004K total,17424K used, 480580K free,34064K cached So I pushed it about 17M into swap. Now let me move over to the other tree and build it just so it won't find anything cached that it can use :-) I am not timing the compiles but they run faster under Rik's patch. Second compile the system looks like this: 19:18:28 up 23 min, 2 users, load average: 8.21, 6.06, 3.23 257 processes: 251 sleeping, 6 running, 0 zombie, 0 stopped CPU states: 24.1% user, 7.6% system, 0.0% nice, 68.2% idle Mem:127028K total,78384K used,48644K free, 976K buffers Swap: 498004K total,19760K used, 478244K free,28992K cached And it completes normally, no hangs. I can pretty much cause 2.4.6-pre2 to "wedge" (for lack of a better description) by just making it busy and having it do something that takes up swap. With Rik's patch everything stayed usable, interactive response was good and I could log in while the compile was running and got good response to the login prompts. Several minutes after the last compile, things are pretty much back to normal: 19:26:14 up 30 min, 2 users, load average: 0.02, 1.27, 1.94 266 processes: 265 sleeping, 1 running, 0 zombie, 0 stopped CPU states: 3.7% user, 8.1% system, 0.0% nice, 88.2% idle Mem:127028K total, 103512K used,23516K free, 1168K buffers Swap: 498004K total, 7768K used, 490236K free,38784K cached I am going to run it a few days and
RE: [PATCH] 2.4.6-pre2 page_launder() improvements
My bad, I just looked at my notes again. It both went away and returned with right around 500 processes. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] 2.4.6-pre2 page_launder() improvements
> > That sounds like the machine just gets a working set > larger than the amount of available memory. It should > work better with eg. 96, 128 or more MBs of memory. Now that I think about it a little more ... once I took it out of the balancer and I got control back, I had over 500 apache kids alive and it was responsive. Also, when top -q starting giving out, it was still updating the screen though it started getting slower and slower ... at that point I only had MAYBE 300 apache processes. It almost felt like the system could not catch up as fast as the new connections were arriving. Lets say it "goes dead" at about 300 or so connections, I let it run for a while then take it out of the rotation and it "comes back" and shows me it has about 500 processes and its interactive response is fine and it is only about 100MB into swap. It just feels like it can't get out of its own way fast enough. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] 2.4.6-pre2 page_launder() improvements
> > That sounds like the machine just gets a working set > larger than the amount of available memory. It should > work better with eg. 96, 128 or more MBs of memory. > Right, I run them with 256M ... thought I would try to squeeze it a bit to see what broke. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] 2.4.6-pre2 page_launder() improvements
> > This patch has given excellent results on my laptop and my > workstation here and seems to improve kernel behaviour in tests > quite a bit. I can play mp3's unbuffered during moderate write > loads or moderately heavy IO ;) > > YMMV, please test it. If it works great for everybody I'd like > to get this improvement merged into the next -pre kernel. For the test I ran it through, it was about the same as 2.4.6-pre2 vanilla. The test I did can be simulated easilly enough. Apache with keepalives off. about 50 connections/second pulling a 10K file. Have half a gig of swap. Told the machine on boot that it had 64MB of RAM. Prestarted 250 apache children. Once everything settles down, I was about 10meg into swap and everything is running smoothly. So far so good. Now I figured I would push it a little more into swap so this being a production server, I can't really tell the world to make more connections so I do the next best thing and turn keepalives on with a timeout of 2 seconds figuring this would increase the number of apache children alive and push me deeper into swap. Restarted apache and within about 5 seconds the machine stopped responding to console input. top would not update the screen but the machine would respond to pings. I took it out of the load balancer and regained control in seconds. The 15 minute load average showed somewhere over 150 with a bazillion apache processes. Even top -q would not update when I put it back into the balancer. The load average and number of processes started to increase until I got to some point where it would just stop providing output. Again, control returned within seconds after taking it out of the balancer. As far as I could tell, I never at any time got more than 100MB into swap. Your patch did seem to keep the machine alive a little longer but that is subjective and I have no data to back that statement up. Vanilla 2.4.6-pre2 seemed to die off a little faster. Again, with both kernels, pings were fine, just no interactive at all. I was logged in over the net with no console so I could not see what was hogging the CPU bot it did not appear to be a user process. That top -q would not update tells me it was likely in the kernel because that runs as the highest priority user process. I just could not get any CPU in user space. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] 2.4.6-pre2 page_launder() improvements
This patch has given excellent results on my laptop and my workstation here and seems to improve kernel behaviour in tests quite a bit. I can play mp3's unbuffered during moderate write loads or moderately heavy IO ;) YMMV, please test it. If it works great for everybody I'd like to get this improvement merged into the next -pre kernel. For the test I ran it through, it was about the same as 2.4.6-pre2 vanilla. The test I did can be simulated easilly enough. Apache with keepalives off. about 50 connections/second pulling a 10K file. Have half a gig of swap. Told the machine on boot that it had 64MB of RAM. Prestarted 250 apache children. Once everything settles down, I was about 10meg into swap and everything is running smoothly. So far so good. Now I figured I would push it a little more into swap so this being a production server, I can't really tell the world to make more connections so I do the next best thing and turn keepalives on with a timeout of 2 seconds figuring this would increase the number of apache children alive and push me deeper into swap. Restarted apache and within about 5 seconds the machine stopped responding to console input. top would not update the screen but the machine would respond to pings. I took it out of the load balancer and regained control in seconds. The 15 minute load average showed somewhere over 150 with a bazillion apache processes. Even top -q would not update when I put it back into the balancer. The load average and number of processes started to increase until I got to some point where it would just stop providing output. Again, control returned within seconds after taking it out of the balancer. As far as I could tell, I never at any time got more than 100MB into swap. Your patch did seem to keep the machine alive a little longer but that is subjective and I have no data to back that statement up. Vanilla 2.4.6-pre2 seemed to die off a little faster. Again, with both kernels, pings were fine, just no interactive at all. I was logged in over the net with no console so I could not see what was hogging the CPU bot it did not appear to be a user process. That top -q would not update tells me it was likely in the kernel because that runs as the highest priority user process. I just could not get any CPU in user space. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] 2.4.6-pre2 page_launder() improvements
That sounds like the machine just gets a working set larger than the amount of available memory. It should work better with eg. 96, 128 or more MBs of memory. Right, I run them with 256M ... thought I would try to squeeze it a bit to see what broke. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] 2.4.6-pre2 page_launder() improvements
That sounds like the machine just gets a working set larger than the amount of available memory. It should work better with eg. 96, 128 or more MBs of memory. Now that I think about it a little more ... once I took it out of the balancer and I got control back, I had over 500 apache kids alive and it was responsive. Also, when top -q starting giving out, it was still updating the screen though it started getting slower and slower ... at that point I only had MAYBE 300 apache processes. It almost felt like the system could not catch up as fast as the new connections were arriving. Lets say it goes dead at about 300 or so connections, I let it run for a while then take it out of the rotation and it comes back and shows me it has about 500 processes and its interactive response is fine and it is only about 100MB into swap. It just feels like it can't get out of its own way fast enough. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] 2.4.6-pre2 page_launder() improvements
My bad, I just looked at my notes again. It both went away and returned with right around 500 processes. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] 2.4.6-pre2 page_launder() improvements
Ok, new test. Apache, no keepalives. 85 requests/sec for a 10K file 128MB of RAM Processor is UP 700MHz Intel vanilla 2.4.6-pre2 After everything settles down I have about 230-250 apache process running. about 4% of CPU in user and roughly 6% in system. Top shows: 18:12:47 up 59 min, 2 users, load average: 1.36, 3.26, 12.76 - from a previous test, 240 processes: 239 sleeping, 1 running, 0 zombie, 0 stopped CPU states: 3.7% user, 6.8% system, 0.0% nice, 89.5% idle Mem:127184K total,95308K used,31876K free,14300K buffers Swap: 498004K total, 5032K used, 492972K free,14244K cached I have about 5MB in swap. Now kick off make -j8 in the linux kernel tree. CPU goes to about 80/20 user/system Top looks like this: 18:21:46 up 1:08, 2 users, load average: 17.71, 12.19, 12.55 299 processes: 290 sleeping, 9 running, 0 zombie, 0 stopped CPU states: 77.4% user, 22.6% system, 0.0% nice, 0.0% idle Mem:127184K total, 124664K used, 2520K free, 2644K buffers Swap: 498004K total,20160K used, 477844K free,11612K cached So I have pushed about 20M into swap with a really busy system (SCSI ext2) I run make -j8 in the source tree and am able to get the machine in a state where it is no longer interactive at the terminal, it seems to be hung, the make is generating nothing, top is not refreshing, machine responds to pings fine. Last top refresh shows: 18:26:41 up 1:13, 3 users, load average: 39.39, 19.70, 14.99 393 processes: 383 sleeping, 10 running, 0 zombie, 0 stopped CPU states: 39.6% user, 35.7% system, 0.0% nice, 24.7% idle Mem:127184K total, 123244K used, 3940K free, 2880K buffers Swap: 498004K total,34504K used, 463500K free,26332K cached I wait about 5 mintes to be sure I am not going to get anything back any time soon. Send cntl-c to the make, it takes abot a minute to quit. top starts refreshing and looks like this: 18:31:55 up 1:19, 3 users, load average: 228.76, 167.10, 80.71 331 processes: 330 sleeping, 1 running, 0 zombie, 0 stopped CPU states: 1.3% user, 27.7% system, 0.0% nice, 71.0% idle Mem:127184K total,87804K used,39380K free, 3184K buffers Swap: 498004K total,31776K used, 466228K free,24856K cached If I try again to run the make -j8 I can not seem to get it to hang again. Figuring it now has something cached that it can get to, I move to a different source tree and run another make -j and it hangs again in a different spot but with the same symptoms. So much for vanilla 2.4.6-pre2. I shut down and reboot into 2.4.6-pre2+Rik's patch. After everything settles down top shows: 19:07:32 up 12 min, 2 users, load average: 0.08, 0.05, 0.00 300 processes: 297 sleeping, 1 running, 2 zombie, 0 stopped CPU states: 5.3% user, 6.7% system, 0.0% nice, 88.0% idle Mem:127028K total, 106788K used,20240K free, 1144K buffers Swap: 498004K total,0K used, 498004K free,27408K cached Hmmm, not in swap at all. Ok ... now lets kick off a make -j8 CPU goes to 85/15 user/system about a 5% difference from the vanilla kernel. About 20MB into swap and the compile is progressing well. Compile finishes with no hangup top looks like: 19:13:19 up 18 min, 2 users, load average: 2.80, 3.89, 1.85 259 processes: 258 sleeping, 1 running, 0 zombie, 0 stopped CPU states: 3.7% user, 6.3% system, 0.0% nice, 90.0% idle Mem:127028K total,87368K used,39660K free, 1276K buffers Swap: 498004K total,17424K used, 480580K free,34064K cached So I pushed it about 17M into swap. Now let me move over to the other tree and build it just so it won't find anything cached that it can use :-) I am not timing the compiles but they run faster under Rik's patch. Second compile the system looks like this: 19:18:28 up 23 min, 2 users, load average: 8.21, 6.06, 3.23 257 processes: 251 sleeping, 6 running, 0 zombie, 0 stopped CPU states: 24.1% user, 7.6% system, 0.0% nice, 68.2% idle Mem:127028K total,78384K used,48644K free, 976K buffers Swap: 498004K total,19760K used, 478244K free,28992K cached And it completes normally, no hangs. I can pretty much cause 2.4.6-pre2 to wedge (for lack of a better description) by just making it busy and having it do something that takes up swap. With Rik's patch everything stayed usable, interactive response was good and I could log in while the compile was running and got good response to the login prompts. Several minutes after the last compile, things are pretty much back to normal: 19:26:14 up 30 min, 2 users, load average: 0.02, 1.27, 1.94 266 processes: 265 sleeping, 1 running, 0 zombie, 0 stopped CPU states: 3.7% user, 8.1% system, 0.0% nice, 88.2% idle Mem:127028K total, 103512K used,23516K free, 1168K buffers Swap: 498004K total, 7768K used, 490236K free,38784K cached I am going to run it a few days and see
2.4.6-pre1 unresolved symbols
depmod: *** Unresolved symbols in /lib/modules/2.4.6-pre1/kernel/drivers/net/3c59x.o depmod: do_softirq depmod: *** Unresolved symbols in /lib/modules/2.4.6-pre1/kernel/drivers/net/bonding.o depmod: do_softirq depmod: *** Unresolved symbols in /lib/modules/2.4.6-pre1/kernel/drivers/net/plip.o depmod: tasklet_hi_schedule depmod: *** Unresolved symbols in /lib/modules/2.4.6-pre1/kernel/drivers/net/ppp_generic.o depmod: do_softirq depmod: *** Unresolved symbols in /lib/modules/2.4.6-pre1/kernel/drivers/net/slip.o depmod: do_softirq depmod: *** Unresolved symbols in /lib/modules/2.4.6-pre1/kernel/drivers/scsi/imm.o depmod: tasklet_hi_schedule depmod: *** Unresolved symbols in /lib/modules/2.4.6-pre1/kernel/drivers/scsi/ppa.o depmod: tasklet_hi_schedule depmod: *** Unresolved symbols in /lib/modules/2.4.6-pre1/kernel/net/ipv6/ipv6.o depmod: do_softirq - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.6-pre1 unresolved symbols
depmod: *** Unresolved symbols in /lib/modules/2.4.6-pre1/kernel/drivers/net/3c59x.o depmod: do_softirq depmod: *** Unresolved symbols in /lib/modules/2.4.6-pre1/kernel/drivers/net/bonding.o depmod: do_softirq depmod: *** Unresolved symbols in /lib/modules/2.4.6-pre1/kernel/drivers/net/plip.o depmod: tasklet_hi_schedule depmod: *** Unresolved symbols in /lib/modules/2.4.6-pre1/kernel/drivers/net/ppp_generic.o depmod: do_softirq depmod: *** Unresolved symbols in /lib/modules/2.4.6-pre1/kernel/drivers/net/slip.o depmod: do_softirq depmod: *** Unresolved symbols in /lib/modules/2.4.6-pre1/kernel/drivers/scsi/imm.o depmod: tasklet_hi_schedule depmod: *** Unresolved symbols in /lib/modules/2.4.6-pre1/kernel/drivers/scsi/ppa.o depmod: tasklet_hi_schedule depmod: *** Unresolved symbols in /lib/modules/2.4.6-pre1/kernel/net/ipv6/ipv6.o depmod: do_softirq - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [OFF-TOPIC] 4 ports ETH cards
> I've been working with these boards for a couple months and thought they > were great. However, now it turns out that they won't fit into our > systems too well (a little too long). Does anyone have knowledge of > another brand that has a (slightly) smaller form factor? I did some > checking on Pricewatch but wasn't able to find anything that fit our > needs. > > TIA, > > -Jeff The Adaptec Quartet64 boards worked ok for me with 2.2 and the Starfire driver. Not sure if they are smaller (shorter) than the D-Link but they sure are a lot shorter than the old Tulip-based Adaptec quad boards. They are a bit pricey, though. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [OFF-TOPIC] 4 ports ETH cards
I've been working with these boards for a couple months and thought they were great. However, now it turns out that they won't fit into our systems too well (a little too long). Does anyone have knowledge of another brand that has a (slightly) smaller form factor? I did some checking on Pricewatch but wasn't able to find anything that fit our needs. TIA, -Jeff The Adaptec Quartet64 boards worked ok for me with 2.2 and the Starfire driver. Not sure if they are smaller (shorter) than the D-Link but they sure are a lot shorter than the old Tulip-based Adaptec quad boards. They are a bit pricey, though. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Crusoe math performance?
So I am fooling around with one of these things: processor : 0 vendor_id : GenuineTMx86 cpu family : 5 model : 4 model name : Transmeta(tm) Crusoe(tm) Processor TM5600 stepping: 3 cpu MHz : 533.348 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr cx8 cmov mmx longrun bogomips: 1032.19 Anyone have any idea of FPU performance? I mean, compared to a Celeron or Pentium in an application running an SSL web server would I expect 80%, 100%, 10%, 110% of the throughput of a Intel chip of the same clock speed? Just thought this thing might be a good alternative to a Pentium SSL server "furnace" and am looking for any comments from anyone that might have tested it. If I don't hear anything, I will post the numbers we come up with when we get around to benchmarking them. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Crusoe math performance?
So I am fooling around with one of these things: processor : 0 vendor_id : GenuineTMx86 cpu family : 5 model : 4 model name : Transmeta(tm) Crusoe(tm) Processor TM5600 stepping: 3 cpu MHz : 533.348 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr cx8 cmov mmx longrun bogomips: 1032.19 Anyone have any idea of FPU performance? I mean, compared to a Celeron or Pentium in an application running an SSL web server would I expect 80%, 100%, 10%, 110% of the throughput of a Intel chip of the same clock speed? Just thought this thing might be a good alternative to a Pentium SSL server furnace and am looking for any comments from anyone that might have tested it. If I don't hear anything, I will post the numbers we come up with when we get around to benchmarking them. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Subjective 2.4.4 performance report
I will know better when the load ramps up next week but 2.4.4 (with Al Viro's prune_icache() patch) just seems to "feel" better than the previous 2.4 kernels did. This is a UP Pentium-III with 256MB RAM used as a web server with about 100 connections open as I write this and serving about 50 requests/sec. Note this machine does not run X or have any users logged in, it is just a plain old web server (Debian Woody and Apache). Now that I have said this it will likely turn into a smoking heap of silicon. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Subjective 2.4.4 performance report
I will know better when the load ramps up next week but 2.4.4 (with Al Viro's prune_icache() patch) just seems to feel better than the previous 2.4 kernels did. This is a UP Pentium-III with 256MB RAM used as a web server with about 100 connections open as I write this and serving about 50 requests/sec. Note this machine does not run X or have any users logged in, it is just a plain old web server (Debian Woody and Apache). Now that I have said this it will likely turn into a smoking heap of silicon. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.4 stable when?
Just to follow up on this ... I am now running 2.4.4pre4 and it seems to be stable. If I reboot the machine (or simply stop and restart apache) the load avg does go much higher than I am used to seeing (near 50 for about 5 minutes or so) it does not hang as previous kernels did. I have the vmstat and top -i info if anyone is curious. It does not touch swap, though. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of George Bonser > Sent: Sunday, April 15, 2001 8:39 AM > To: Rik van Riel > Cc: [EMAIL PROTECTED] > Subject: RE: 2.4 stable when? > > > > > > > Is there any information that would be helpful to the kernel > > > developers that I might be able to provide or is this a known issue > > > that is currently being worked out? > > > > I never heard about this problem. What would be helpful is to > > send a few minutes' (a full 'load cycle'?) worth of output from > > 'vmstat 5' and some information about the configuration of the > > machine. > > > > It's possible I'll want more information later, but just the > > vmstat output would be a good start. > > > > If the data isn't too big, I'd appreciate it if you could also > > CC [EMAIL PROTECTED] > > > > regards, > > Sounds good. I think I can do this. Also, it appears that the problem is > related to how busy the farm is. The machines are load balanced > in a "least > connections" mode. There are 5 servers in the farm. Suppose I have 300 > connections to each machine and reboot one to load the new kernel. > > When that server comes back up it is handed 300 connections all > at once. It > seems (and this is subjective ... does it handle things differently with > more than 256 processes?) that when I give the machine much more than 200 > connections, it is very slow to clear them. It seems to have trouble at > that point clearing connections as fast as it is getting them. If I have > less than 200 connections initially, it seems to handle things OK. > > I tried to collect some data last night but it appeared to work ok. I will > wait for the load to come up later today and try it during its peak time. > While I could put the balancer into a "slow start" mode, 2.2 always seemed > to handle the burst of new connections just fine so I didn't bother. > > The machine is a UP Pentium-III 800MHz with 512MB of RAM running Debian > Woody. It is a SuperMicro 6010L 1U unit with the SuperMicro 370DLR > motherboard. This uses the ServerWorks ServerSet III LE chipset > and Adaptec > AIC-7892 Ultra160 disk controller and on-board dual Intel NIC (only using > eth0). > > I have cut the configuration pretty much to the bone, no > NetFilter support, > no QoS, no Audio/Video. Tried to get it as plain vanilla as possible (my > first step when having problems). > > I was able to run 2.4.0-test12 in this application and did for quite some > time. I don't recall trying 2.4.1 but I know I had severe problems with > 2.4.2 and 2.4.3. Now that I think about it, I am not sure the farm was as > busy back when I put 2.4.0 on it or that I ever rebooted during my peak > period. This might have been a problem all along but I just never > saw it. It > seems to have to do with handing the machine a large number of connections > at once and then a stream of them at a pretty good clip. It is > getting about > 40 connections/second right this minute but that should come up a > bit in the > next couple of hours. > > To be quite honest, I could run this on 2.2 forever, it is just a > webserver. > My only reason for using 2.4 would be to see if I can go SMP on > these things > when my load gets higher and I get some benefit of the finer > granularity of > 2.4 in SMP to serve a higher load with fewer machines than would > be possible > with 2.2. That, and just to beat on a 2.4 kernel and report any > problems to > you guys. > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.4 stable when?
Just to follow up on this ... I am now running 2.4.4pre4 and it seems to be stable. If I reboot the machine (or simply stop and restart apache) the load avg does go much higher than I am used to seeing (near 50 for about 5 minutes or so) it does not hang as previous kernels did. I have the vmstat and top -i info if anyone is curious. It does not touch swap, though. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of George Bonser Sent: Sunday, April 15, 2001 8:39 AM To: Rik van Riel Cc: [EMAIL PROTECTED] Subject: RE: 2.4 stable when? Is there any information that would be helpful to the kernel developers that I might be able to provide or is this a known issue that is currently being worked out? I never heard about this problem. What would be helpful is to send a few minutes' (a full 'load cycle'?) worth of output from 'vmstat 5' and some information about the configuration of the machine. It's possible I'll want more information later, but just the vmstat output would be a good start. If the data isn't too big, I'd appreciate it if you could also CC [EMAIL PROTECTED] regards, Sounds good. I think I can do this. Also, it appears that the problem is related to how busy the farm is. The machines are load balanced in a "least connections" mode. There are 5 servers in the farm. Suppose I have 300 connections to each machine and reboot one to load the new kernel. When that server comes back up it is handed 300 connections all at once. It seems (and this is subjective ... does it handle things differently with more than 256 processes?) that when I give the machine much more than 200 connections, it is very slow to clear them. It seems to have trouble at that point clearing connections as fast as it is getting them. If I have less than 200 connections initially, it seems to handle things OK. I tried to collect some data last night but it appeared to work ok. I will wait for the load to come up later today and try it during its peak time. While I could put the balancer into a "slow start" mode, 2.2 always seemed to handle the burst of new connections just fine so I didn't bother. The machine is a UP Pentium-III 800MHz with 512MB of RAM running Debian Woody. It is a SuperMicro 6010L 1U unit with the SuperMicro 370DLR motherboard. This uses the ServerWorks ServerSet III LE chipset and Adaptec AIC-7892 Ultra160 disk controller and on-board dual Intel NIC (only using eth0). I have cut the configuration pretty much to the bone, no NetFilter support, no QoS, no Audio/Video. Tried to get it as plain vanilla as possible (my first step when having problems). I was able to run 2.4.0-test12 in this application and did for quite some time. I don't recall trying 2.4.1 but I know I had severe problems with 2.4.2 and 2.4.3. Now that I think about it, I am not sure the farm was as busy back when I put 2.4.0 on it or that I ever rebooted during my peak period. This might have been a problem all along but I just never saw it. It seems to have to do with handing the machine a large number of connections at once and then a stream of them at a pretty good clip. It is getting about 40 connections/second right this minute but that should come up a bit in the next couple of hours. To be quite honest, I could run this on 2.2 forever, it is just a webserver. My only reason for using 2.4 would be to see if I can go SMP on these things when my load gets higher and I get some benefit of the finer granularity of 2.4 in SMP to serve a higher load with fewer machines than would be possible with 2.2. That, and just to beat on a 2.4 kernel and report any problems to you guys. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.4 stable when?
> > > Is there any information that would be helpful to the kernel > > developers that I might be able to provide or is this a known issue > > that is currently being worked out? > > I never heard about this problem. What would be helpful is to > send a few minutes' (a full 'load cycle'?) worth of output from > 'vmstat 5' and some information about the configuration of the > machine. > > It's possible I'll want more information later, but just the > vmstat output would be a good start. > > If the data isn't too big, I'd appreciate it if you could also > CC [EMAIL PROTECTED] > > regards, Sounds good. I think I can do this. Also, it appears that the problem is related to how busy the farm is. The machines are load balanced in a "least connections" mode. There are 5 servers in the farm. Suppose I have 300 connections to each machine and reboot one to load the new kernel. When that server comes back up it is handed 300 connections all at once. It seems (and this is subjective ... does it handle things differently with more than 256 processes?) that when I give the machine much more than 200 connections, it is very slow to clear them. It seems to have trouble at that point clearing connections as fast as it is getting them. If I have less than 200 connections initially, it seems to handle things OK. I tried to collect some data last night but it appeared to work ok. I will wait for the load to come up later today and try it during its peak time. While I could put the balancer into a "slow start" mode, 2.2 always seemed to handle the burst of new connections just fine so I didn't bother. The machine is a UP Pentium-III 800MHz with 512MB of RAM running Debian Woody. It is a SuperMicro 6010L 1U unit with the SuperMicro 370DLR motherboard. This uses the ServerWorks ServerSet III LE chipset and Adaptec AIC-7892 Ultra160 disk controller and on-board dual Intel NIC (only using eth0). I have cut the configuration pretty much to the bone, no NetFilter support, no QoS, no Audio/Video. Tried to get it as plain vanilla as possible (my first step when having problems). I was able to run 2.4.0-test12 in this application and did for quite some time. I don't recall trying 2.4.1 but I know I had severe problems with 2.4.2 and 2.4.3. Now that I think about it, I am not sure the farm was as busy back when I put 2.4.0 on it or that I ever rebooted during my peak period. This might have been a problem all along but I just never saw it. It seems to have to do with handing the machine a large number of connections at once and then a stream of them at a pretty good clip. It is getting about 40 connections/second right this minute but that should come up a bit in the next couple of hours. To be quite honest, I could run this on 2.2 forever, it is just a webserver. My only reason for using 2.4 would be to see if I can go SMP on these things when my load gets higher and I get some benefit of the finer granularity of 2.4 in SMP to serve a higher load with fewer machines than would be possible with 2.2. That, and just to beat on a 2.4 kernel and report any problems to you guys. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.4 stable when?
Is there any information that would be helpful to the kernel developers that I might be able to provide or is this a known issue that is currently being worked out? I never heard about this problem. What would be helpful is to send a few minutes' (a full 'load cycle'?) worth of output from 'vmstat 5' and some information about the configuration of the machine. It's possible I'll want more information later, but just the vmstat output would be a good start. If the data isn't too big, I'd appreciate it if you could also CC [EMAIL PROTECTED] regards, Sounds good. I think I can do this. Also, it appears that the problem is related to how busy the farm is. The machines are load balanced in a "least connections" mode. There are 5 servers in the farm. Suppose I have 300 connections to each machine and reboot one to load the new kernel. When that server comes back up it is handed 300 connections all at once. It seems (and this is subjective ... does it handle things differently with more than 256 processes?) that when I give the machine much more than 200 connections, it is very slow to clear them. It seems to have trouble at that point clearing connections as fast as it is getting them. If I have less than 200 connections initially, it seems to handle things OK. I tried to collect some data last night but it appeared to work ok. I will wait for the load to come up later today and try it during its peak time. While I could put the balancer into a "slow start" mode, 2.2 always seemed to handle the burst of new connections just fine so I didn't bother. The machine is a UP Pentium-III 800MHz with 512MB of RAM running Debian Woody. It is a SuperMicro 6010L 1U unit with the SuperMicro 370DLR motherboard. This uses the ServerWorks ServerSet III LE chipset and Adaptec AIC-7892 Ultra160 disk controller and on-board dual Intel NIC (only using eth0). I have cut the configuration pretty much to the bone, no NetFilter support, no QoS, no Audio/Video. Tried to get it as plain vanilla as possible (my first step when having problems). I was able to run 2.4.0-test12 in this application and did for quite some time. I don't recall trying 2.4.1 but I know I had severe problems with 2.4.2 and 2.4.3. Now that I think about it, I am not sure the farm was as busy back when I put 2.4.0 on it or that I ever rebooted during my peak period. This might have been a problem all along but I just never saw it. It seems to have to do with handing the machine a large number of connections at once and then a stream of them at a pretty good clip. It is getting about 40 connections/second right this minute but that should come up a bit in the next couple of hours. To be quite honest, I could run this on 2.2 forever, it is just a webserver. My only reason for using 2.4 would be to see if I can go SMP on these things when my load gets higher and I get some benefit of the finer granularity of 2.4 in SMP to serve a higher load with fewer machines than would be possible with 2.2. That, and just to beat on a 2.4 kernel and report any problems to you guys. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Disorder?
> > What kernel are you running? That is 2.4.4-pre3 > This is disabled by default. search for > where FASTRETRANS_DEBUG is enabled (should be in linux/include/net/tcp.h > and set it someting low (like 1 which is the default. The actual error > message comes up in tcp_input.c (search fro FASTRETRANS_DEBUG). > > Regards, > Bart. Thanks, Bart. Looks like it was set to 2. I have set it to 1 and will build it again. I am trying to figure out why 2.4.4 (or to be more accurate 2.4.>1) dies on me when running in my web farm. This last time I tried running top in the background with: top -b -i -d10 >crap & And it has run like a champ! First time I have ever been able to run it with good performance for more than 15 minutes. Maybe I will just substitute /dev/null for crap and that will fix it :-/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Disorder?
What's all this in syslog? I don't remember ever seeing it there before. ... Apr 14 13:58:31 foo kernel: Disorder0 3 5 f0 s2 rr1 Apr 14 13:58:32 foo kernel: Disorder0 3 5 f0 s1 rr1 Apr 14 13:58:41 foo kernel: Disorder0 3 8 f0 s0 rr1 Apr 14 13:58:44 foo kernel: Disorder0 3 5 f0 s0 rr1 Apr 14 13:58:45 foo kernel: Disorder0 3 4 f0 s0 rr1 Apr 14 13:58:47 foo kernel: Disorder0 3 5 f0 s0 rr1 Apr 14 13:58:55 foo kernel: Disorder3 1 5 f5 s2 rr0 Apr 14 13:58:59 foo kernel: Undo Hoe 145.236.164.120/2007 c3 l0 ss2/2 p3 Apr 14 13:59:00 foo kernel: Disorder0 3 5 f0 s0 rr1 Apr 14 13:59:01 foo kernel: Disorder0 3 5 f0 s0 rr1 Apr 14 13:59:02 foo kernel: Undo Hoe 145.236.164.120/2007 c3 l0 ss2/2 p2 Apr 14 13:59:02 foo kernel: Disorder0 3 4 f0 s0 rr1 Apr 14 13:59:03 foo kernel: Undo Hoe 145.236.164.120/2007 c3 l0 ss2/2 p1 Apr 14 13:59:04 foo kernel: Undo retrans 145.236.164.120/2007 c2 l0 ss2/2 p0 Apr 14 13:59:11 foo kernel: Disorder0 3 5 f0 s0 rr1 Apr 14 13:59:15 foo kernel: Disorder0 3 4 f0 s0 rr1 Apr 14 13:59:17 foo kernel: Disorder0 3 5 f0 s0 rr1 Apr 14 13:59:19 foo kernel: Disorder0 3 4 f0 s0 rr1 Apr 14 13:59:21 foo kernel: Disorder0 3 4 f0 s0 rr1 Apr 14 13:59:24 foo kernel: Disorder0 3 7 f0 s0 rr1 Apr 14 13:59:25 foo kernel: Disorder0 3 5 f0 s0 rr1 Apr 14 13:59:37 foo kernel: Disorder0 3 5 f0 s0 rr1 Apr 14 13:59:57 foo kernel: Disorder3 1 5 f5 s2 rr0 ... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4 stable when?
I have a web server farm that right now has about 125 apache processes running per machine. If I try to use 2.4.3 or even 2.4.3-ac6 it will go to about 400 (meaning it is slow in clearing connections), the load average will start to climb until it gets to close to 100 and then stops responding. It runs ok for about the first 5 minutes of its life and then sinks deeper and deeper into the mire until it disappears. No processes are shown stuck in D state. 2.4.4pre3 works, sorta, but is very "pumpy". The load avg will go up to about 60, then drop, then climb again, then drop. It will vary from very sluggish performance to snappy and back again to sluggish. With 2.2 kernels I see something like this: 00:48:00 up 4:51, 1 user, load average: 0.00, 0.02, 0.06 141 processes: 139 sleeping, 2 running, 0 zombie, 0 stopped CPU states: 2.8% user, 3.2% system, 0.0% nice, 94.1% idle and that is with about 120 remote users connected to the box via apache. Is there any information that would be helpful to the kernel developers that I might be able to provide or is this a known issue that is currently being worked out? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4 stable when?
I have a web server farm that right now has about 125 apache processes running per machine. If I try to use 2.4.3 or even 2.4.3-ac6 it will go to about 400 (meaning it is slow in clearing connections), the load average will start to climb until it gets to close to 100 and then stops responding. It runs ok for about the first 5 minutes of its life and then sinks deeper and deeper into the mire until it disappears. No processes are shown stuck in D state. 2.4.4pre3 works, sorta, but is very "pumpy". The load avg will go up to about 60, then drop, then climb again, then drop. It will vary from very sluggish performance to snappy and back again to sluggish. With 2.2 kernels I see something like this: 00:48:00 up 4:51, 1 user, load average: 0.00, 0.02, 0.06 141 processes: 139 sleeping, 2 running, 0 zombie, 0 stopped CPU states: 2.8% user, 3.2% system, 0.0% nice, 94.1% idle and that is with about 120 remote users connected to the box via apache. Is there any information that would be helpful to the kernel developers that I might be able to provide or is this a known issue that is currently being worked out? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Disorder?
What kernel are you running? That is 2.4.4-pre3 This is disabled by default. search for where FASTRETRANS_DEBUG is enabled (should be in linux/include/net/tcp.h and set it someting low (like 1 which is the default. The actual error message comes up in tcp_input.c (search fro FASTRETRANS_DEBUG). Regards, Bart. Thanks, Bart. Looks like it was set to 2. I have set it to 1 and will build it again. I am trying to figure out why 2.4.4 (or to be more accurate 2.4.1) dies on me when running in my web farm. This last time I tried running top in the background with: top -b -i -d10 crap And it has run like a champ! First time I have ever been able to run it with good performance for more than 15 minutes. Maybe I will just substitute /dev/null for crap and that will fix it :-/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.4-pre2 nbd compile error
gcc -D__KERNEL__ -I/usr/local/src/linux/include -Wall -Wstrict-prototypes -O 2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary =2 -march=i686 -DMODULE -DMODVERSIONS -include /usr/local/src/linux/include/linux/modversions.h -c -o nbd.o nbd.c nbd.c: In function `nbd_send_req': nbd.c:160: `MSG_MORE' undeclared (first use in this function) nbd.c:160: (Each undeclared identifier is reported only once nbd.c:160: for each function it appears in.) nbd.c: At top level: nbd.c:481: warning: static declaration for `nbd_init' follows non-static - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.4-pre2 nbd compile error
gcc -D__KERNEL__ -I/usr/local/src/linux/include -Wall -Wstrict-prototypes -O 2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary =2 -march=i686 -DMODULE -DMODVERSIONS -include /usr/local/src/linux/include/linux/modversions.h -c -o nbd.o nbd.c nbd.c: In function `nbd_send_req': nbd.c:160: `MSG_MORE' undeclared (first use in this function) nbd.c:160: (Each undeclared identifier is reported only once nbd.c:160: for each function it appears in.) nbd.c: At top level: nbd.c:481: warning: static declaration for `nbd_init' follows non-static - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: New directions for kernel development
So according to the below, Linux development should be considered an environmental hazard? Maybe it is in the best interest of Planet Earth that we should provide some safe place, possibly some South Pacific island, where we could set up a quarrantine camp for hardcore linux developers. All of their needs would be provided for, of course, since it is not their fault they are afflicted with this problem. Someplace near an undersea fiber link would most likely be best since their activities will need to be closely monitored at all times and instant global communication of their "progress" is vital. Judging from the pasty faces of many Linux developers, sunshine might be the perfect remedy. I say the UN should get right on this problem straight away! > Secondly, I'd like to address the issue of cleanliness. > Quite frankly, the > standards of personal hygiene practiced by many members of this community > are simply unacceptable. > I am sorry to sound so harsh, but a little hygiene every once in a > while is a Good Thing(TM). > Alan views toothpaste the same way a vampire views garlic. > I have nearly fainted from the torrent of rotten odor that pours > from every inch of his toxic person. > If you have to meet with > ESR for any reason, arrange for the meeting to be outdoors and try to stay > upwind. > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: New directions for kernel development
So according to the below, Linux development should be considered an environmental hazard? Maybe it is in the best interest of Planet Earth that we should provide some safe place, possibly some South Pacific island, where we could set up a quarrantine camp for hardcore linux developers. All of their needs would be provided for, of course, since it is not their fault they are afflicted with this problem. Someplace near an undersea fiber link would most likely be best since their activities will need to be closely monitored at all times and instant global communication of their "progress" is vital. Judging from the pasty faces of many Linux developers, sunshine might be the perfect remedy. I say the UN should get right on this problem straight away! Secondly, I'd like to address the issue of cleanliness. Quite frankly, the standards of personal hygiene practiced by many members of this community are simply unacceptable. I am sorry to sound so harsh, but a little hygiene every once in a while is a Good Thing(TM). Alan views toothpaste the same way a vampire views garlic. I have nearly fainted from the torrent of rotten odor that pours from every inch of his toxic person. If you have to meet with ESR for any reason, arrange for the meeting to be outdoors and try to stay upwind. Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.3 aic7xxx nevermind
I grabbed a complete 2.4.3 tarball and that seems to have fixed the problem. Something must have gotten borked in the patching process somewhere. And the sad part is that I know to do that before posting ... :-( - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.3 aic7xxx wont compile
Just tried to build 2.4.3, got: make[6]: Entering directory `/usr/local/src/linux/drivers/scsi/aic7xxx/aicasm' gcc -I/usr/include -ldb1 aicasm_gram.c aicasm_scan.c aicasm.c aicasm_symbol.c -o aicasm aicasm/aicasm_gram.y:45: ../queue.h: No such file or directory aicasm/aicasm_gram.y:50: aicasm.h: No such file or directory aicasm/aicasm_gram.y:51: aicasm_symbol.h: No such file or directory aicasm/aicasm_gram.y:52: aicasm_insformat.h: No such file or directory aicasm/aicasm_scan.l:44: ../queue.h: No such file or directory aicasm/aicasm_scan.l:49: aicasm.h: No such file or directory aicasm/aicasm_scan.l:50: aicasm_symbol.h: No such file or directory aicasm/aicasm_scan.l:51: y.tab.h: No such file or directory make[6]: *** [aicasm] Error 1 make[6]: Leaving directory `/usr/local/src/linux/drivers/scsi/aic7xxx/aicasm' ... Looks like something's missing here. Had 2.4.2 patched to 2.4.3-pre7, backed out pre7 and applied 2.4.3. A patch has not hit the archive I use and I have just subscribed. Anyone have a fix for this? I gotta have aic7xxx support, its my boot disk controller. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.3 aic7xxx wont compile
Just tried to build 2.4.3, got: make[6]: Entering directory `/usr/local/src/linux/drivers/scsi/aic7xxx/aicasm' gcc -I/usr/include -ldb1 aicasm_gram.c aicasm_scan.c aicasm.c aicasm_symbol.c -o aicasm aicasm/aicasm_gram.y:45: ../queue.h: No such file or directory aicasm/aicasm_gram.y:50: aicasm.h: No such file or directory aicasm/aicasm_gram.y:51: aicasm_symbol.h: No such file or directory aicasm/aicasm_gram.y:52: aicasm_insformat.h: No such file or directory aicasm/aicasm_scan.l:44: ../queue.h: No such file or directory aicasm/aicasm_scan.l:49: aicasm.h: No such file or directory aicasm/aicasm_scan.l:50: aicasm_symbol.h: No such file or directory aicasm/aicasm_scan.l:51: y.tab.h: No such file or directory make[6]: *** [aicasm] Error 1 make[6]: Leaving directory `/usr/local/src/linux/drivers/scsi/aic7xxx/aicasm' ... Looks like something's missing here. Had 2.4.2 patched to 2.4.3-pre7, backed out pre7 and applied 2.4.3. A patch has not hit the archive I use and I have just subscribed. Anyone have a fix for this? I gotta have aic7xxx support, its my boot disk controller. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
