Re: [ck] Re: Linux Kernel cfs scheduler and xorg kbd
On 8/2/07, <::.. Teresa_II ..::> <[EMAIL PROTECTED]> wrote: > As i sad. I wasn't sure if its kernel related at all, it just was worse > first time i booted cfs-v19.1 patch. Now i cant reproduce it even > anymore :) Hi Teresa, Are you sure its not just a setting in Gnome/KDE for accessibility? That tends to do crazy things like making control keys sticky... -- Matt - 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: [ck] Re: SD still better than CFS for 3d ?
On 8/1/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: > But there's not much value in benchmarking if an important part of the > performance critical code is in some undebuggable driver... In this case we don't care about the performance of the video driver. This isn't a race to see who can get the most fps. The driver can be thought of as a black box so long as comparative benchmarks are done with the same driver. What we're looking for primarily is progress or regress in interactivity under load with different cpu schedulers, and secondly the effect of swap prefetch. The video driver is irrelevant - especially considering the people doing this testing have a wide variety of video cards. This is why I have included some commentary on "feel" because that's the important part. Ingo specifically asked for CFS v20 in 2.6.23 to be included in the testing (its not available separately on his website), hence the need to be able to bring up one's usual working environment under that kernel also so the results aren't skewed by driver artifacts. For my next trick, I'll attempt to quantify the "feel" bits using scheduler statistics. While riding a unicycle. Okay, scratch the unicycle ;-) -- Matt - 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: [ck] Re: SD still better than CFS for 3d ?
On 8/1/07, Adrian Bunk [EMAIL PROTECTED] wrote: But there's not much value in benchmarking if an important part of the performance critical code is in some undebuggable driver... In this case we don't care about the performance of the video driver. This isn't a race to see who can get the most fps. The driver can be thought of as a black box so long as comparative benchmarks are done with the same driver. What we're looking for primarily is progress or regress in interactivity under load with different cpu schedulers, and secondly the effect of swap prefetch. The video driver is irrelevant - especially considering the people doing this testing have a wide variety of video cards. This is why I have included some commentary on feel because that's the important part. Ingo specifically asked for CFS v20 in 2.6.23 to be included in the testing (its not available separately on his website), hence the need to be able to bring up one's usual working environment under that kernel also so the results aren't skewed by driver artifacts. For my next trick, I'll attempt to quantify the feel bits using scheduler statistics. While riding a unicycle. Okay, scratch the unicycle ;-) -- Matt - 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: [ck] Re: Linux Kernel cfs scheduler and xorg kbd
On 8/2/07, ::.. Teresa_II ..:: [EMAIL PROTECTED] wrote: As i sad. I wasn't sure if its kernel related at all, it just was worse first time i booted cfs-v19.1 patch. Now i cant reproduce it even anymore :) Hi Teresa, Are you sure its not just a setting in Gnome/KDE for accessibility? That tends to do crazy things like making control keys sticky... -- Matt - 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: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On 8/1/07, Miguel Figueiredo <[EMAIL PROTECTED]> wrote: > Have you tryied the 2 modes of the patch? Here's my stats for sched_yield_ctl = 2 loops fps 0 48 1 48 2 48 3 48 4 39 5 39 6 39 7 28 8 28 9 22 10 18 Once again it was very jerky come run-around-the-map time, though it improved over time. For me, still not as smooth as CFS was (especially the initial player movement, which was the worst by far of any test so far) I want to get some better numbers than plain fps though, the graph of the numbers is more staircase-like in this test but what it doesn't show is exactly what's going on. I can assure you the framerates may be similar but the gameplay isn't - and in this test 5fps difference is meaningless since it jumps around a lot (especially during the run-around) as you would expect with the different stuff needing to be rendered. -- Matt - 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: [ck] Re: -mm merge plans for 2.6.23
On 7/25/07, Nick Piggin <[EMAIL PROTECTED]> wrote: > I guess /proc/meminfo, /proc/zoneinfo, /proc/vmstat, /proc/slabinfo > before and after the updatedb run with the latest kernel would be a > first step. top and vmstat output during the run wouldn't hurt either. Hi Nick, I've attached two files with this kind of info. Being up at the cron hours of the morning meant I got a better picture of what my system is doing. Here's a short summary of what I saw in top: beagleindexer used gobs of ram. 600M or so (I have 1G) updatedb didn't use much ram, but while it was running kswapd kept on frequenting the top 10 cpu hogs - it would stick around for 5 seconds or so then disappear for no more than 10 seconds, then come back again. This behaviour persisted during the run. updatedb ran third (beagleindexer was first, then update-dlocatedb) I'm going to do this again, this time under a CFS kernel & use Ingo's sched_debug script to see what the scheduler is doing also. Let me know if there's anything else you wish to see. The running kernel at the time was 2.6.22.1-ck. There's no slabinfo since I'm using slub instead (and I don't have slub debug enabled). Cheers, -- Matt beaglecron.ck Description: Binary data updatedbcron.ck Description: Binary data
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On 8/1/07, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > The only other thing of interest is that the -ck kernel had the WM > > menus appear in about 3 seconds rather than 5-8 under the other two. > > under what load is that - 10 loops? There's no disk or network IO going > on during a WM menu appearance, correct? Incorrect. This is before doing any tests whatsoever, just using the menu to get to the launcher for nexuiz. E-17 wants to load up pretty little icons next to every menu item, and "games" is fourth down the list of menus... the three above it contain practically everything else installed on the system (since it includes Applications). Thanks, debian menu! ;) So obviously on first load these things aren't cached yet (in E's own cache), so its madly searching the disk for pretty little icons. After caching, the games menu pops up in 2 seconds. For the newly-tested kernel (-ck+sched_yield_hack) it was 4-5 seconds for initial load, same as CFS normally does for me. I think the 8 second one was because I got in quick and the system was still running some startup crap (so I blame disk i/o not the scheduler). I'll keep an eye on it just in case, but hardly consider it a regression at this stage. Thanks for the other experimentation hints, its always nice to have that little extra bit of documentation! -- Matt - 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: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On 7/31/07, Miguel Figueiredo <[EMAIL PROTECTED]> wrote: > CFS does not requeue_task() on SCHED_YIELD (used by graphic drivers) as until > 2.6.22 and -ck. Please try this hack [1] that makes -ck to behave like CFS > then you are comparing apples to apples. Hi Miguel, I tested with sched_yield_ctl set to 1 2.6.22.1-ck+sched_yield_hack 0 51 1 51 2 51 3 46 4 38 5 38 6 38 7 30 8 27 9 22 10 20 After getting the numbers on all setups with the 10 loops still running I went for a run around the map (I used the "aggressor" map, if anyone cares). CFS was noticeably smoother (despite the small framerate differences). ie CFS was bordering on barely playable, whereas the above test it wasn't really playable (felt like playing on a lagged server). Even plain -ck was better (going for a run, the FPS jumped from ~2 to 15). I've noticed messing with sched_yield tends to cause strange defects in the past... -- Matt - 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: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On 7/31/07, Ingo Molnar <[EMAIL PROTECTED]> wrote: > * Kenneth Prugh <[EMAIL PROTECTED]> wrote: > > CFS generally seemed a lot smoother as the load increased, while SD > > broke down to a highly unstable fps count that fluctuated massively > > around the third loop. Seems like I will stick to CFS for gaming now. My experience was quite similar. I noticed after launching the second loop that the FPS stuck down to 15 for about 20 seconds, then climbed back up to 48. After that it went rapidly downhill. This is similar to other benchmarks I've done of SD versus CFS in the past. At a "normal" load they're fairly similar but SD breaks down under pressure. The only other thing of interest is that the -ck kernel had the WM menus appear in about 3 seconds rather than 5-8 under the other two. Game: Nexuiz 2.3 OpenGL 2.0 shaders on Vertex Buffer Objects on Show FPS on ultimate quality 1024x768 2.6.23-git 0 48 1 48 2 48 3 48 4 40 5 38 6 33 7 28 8 22 9 22 10 18 2.6.22.1-ck 0 48 1 48 2 48 3 12 4 6 5 6 6 5 7 4 8 3 9 3 10 2 2.6.22.1-cfs-v19.1+ckbits [*] 0 48 1 48 2 48 3 46 4 45 5 43 6 36 7 32 8 25 9 24 10 24 [*] This kernel has the cfq-* and mm-* patches from -ck applied, and the above-background-load function from pre-SD ck patchsets (or 2.6.23-git) -- Matt - 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: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On 7/31/07, Ingo Molnar [EMAIL PROTECTED] wrote: * Kenneth Prugh [EMAIL PROTECTED] wrote: CFS generally seemed a lot smoother as the load increased, while SD broke down to a highly unstable fps count that fluctuated massively around the third loop. Seems like I will stick to CFS for gaming now. My experience was quite similar. I noticed after launching the second loop that the FPS stuck down to 15 for about 20 seconds, then climbed back up to 48. After that it went rapidly downhill. This is similar to other benchmarks I've done of SD versus CFS in the past. At a normal load they're fairly similar but SD breaks down under pressure. The only other thing of interest is that the -ck kernel had the WM menus appear in about 3 seconds rather than 5-8 under the other two. Game: Nexuiz 2.3 OpenGL 2.0 shaders on Vertex Buffer Objects on Show FPS on ultimate quality 1024x768 2.6.23-git 0 48 1 48 2 48 3 48 4 40 5 38 6 33 7 28 8 22 9 22 10 18 2.6.22.1-ck 0 48 1 48 2 48 3 12 4 6 5 6 6 5 7 4 8 3 9 3 10 2 2.6.22.1-cfs-v19.1+ckbits [*] 0 48 1 48 2 48 3 46 4 45 5 43 6 36 7 32 8 25 9 24 10 24 [*] This kernel has the cfq-* and mm-* patches from -ck applied, and the above-background-load function from pre-SD ck patchsets (or 2.6.23-git) -- Matt - 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: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On 7/31/07, Miguel Figueiredo [EMAIL PROTECTED] wrote: CFS does not requeue_task() on SCHED_YIELD (used by graphic drivers) as until 2.6.22 and -ck. Please try this hack [1] that makes -ck to behave like CFS then you are comparing apples to apples. Hi Miguel, I tested with sched_yield_ctl set to 1 2.6.22.1-ck+sched_yield_hack 0 51 1 51 2 51 3 46 4 38 5 38 6 38 7 30 8 27 9 22 10 20 After getting the numbers on all setups with the 10 loops still running I went for a run around the map (I used the aggressor map, if anyone cares). CFS was noticeably smoother (despite the small framerate differences). ie CFS was bordering on barely playable, whereas the above test it wasn't really playable (felt like playing on a lagged server). Even plain -ck was better (going for a run, the FPS jumped from ~2 to 15). I've noticed messing with sched_yield tends to cause strange defects in the past... -- Matt - 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: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On 8/1/07, Ingo Molnar [EMAIL PROTECTED] wrote: The only other thing of interest is that the -ck kernel had the WM menus appear in about 3 seconds rather than 5-8 under the other two. under what load is that - 10 loops? There's no disk or network IO going on during a WM menu appearance, correct? Incorrect. This is before doing any tests whatsoever, just using the menu to get to the launcher for nexuiz. E-17 wants to load up pretty little icons next to every menu item, and games is fourth down the list of menus... the three above it contain practically everything else installed on the system (since it includes Applications). Thanks, debian menu! ;) So obviously on first load these things aren't cached yet (in E's own cache), so its madly searching the disk for pretty little icons. After caching, the games menu pops up in 2 seconds. For the newly-tested kernel (-ck+sched_yield_hack) it was 4-5 seconds for initial load, same as CFS normally does for me. I think the 8 second one was because I got in quick and the system was still running some startup crap (so I blame disk i/o not the scheduler). I'll keep an eye on it just in case, but hardly consider it a regression at this stage. Thanks for the other experimentation hints, its always nice to have that little extra bit of documentation! -- Matt - 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: [ck] Re: -mm merge plans for 2.6.23
On 7/25/07, Nick Piggin [EMAIL PROTECTED] wrote: I guess /proc/meminfo, /proc/zoneinfo, /proc/vmstat, /proc/slabinfo before and after the updatedb run with the latest kernel would be a first step. top and vmstat output during the run wouldn't hurt either. Hi Nick, I've attached two files with this kind of info. Being up at the cron hours of the morning meant I got a better picture of what my system is doing. Here's a short summary of what I saw in top: beagleindexer used gobs of ram. 600M or so (I have 1G) updatedb didn't use much ram, but while it was running kswapd kept on frequenting the top 10 cpu hogs - it would stick around for 5 seconds or so then disappear for no more than 10 seconds, then come back again. This behaviour persisted during the run. updatedb ran third (beagleindexer was first, then update-dlocatedb) I'm going to do this again, this time under a CFS kernel use Ingo's sched_debug script to see what the scheduler is doing also. Let me know if there's anything else you wish to see. The running kernel at the time was 2.6.22.1-ck. There's no slabinfo since I'm using slub instead (and I don't have slub debug enabled). Cheers, -- Matt beaglecron.ck Description: Binary data updatedbcron.ck Description: Binary data
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On 8/1/07, Miguel Figueiredo [EMAIL PROTECTED] wrote: Have you tryied the 2 modes of the patch? Here's my stats for sched_yield_ctl = 2 loops fps 0 48 1 48 2 48 3 48 4 39 5 39 6 39 7 28 8 28 9 22 10 18 Once again it was very jerky come run-around-the-map time, though it improved over time. For me, still not as smooth as CFS was (especially the initial player movement, which was the worst by far of any test so far) I want to get some better numbers than plain fps though, the graph of the numbers is more staircase-like in this test but what it doesn't show is exactly what's going on. I can assure you the framerates may be similar but the gameplay isn't - and in this test 5fps difference is meaningless since it jumps around a lot (especially during the run-around) as you would expect with the different stuff needing to be rendered. -- Matt - 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: [ck] Re: SD still better than CFS for 3d ?
On 7/31/07, Roland Dreier <[EMAIL PROTECTED]> wrote: > > Fuck you Martin! > > I think you meant to yell at Matthew, not Martin ;) What's amusing about this is he's yelling at me for something I didn't do, can't even get my name right, and has the audacity to claim that *I* am the one looking like a fool! While we're descending into primary school theatrics, may I just say "takes one to know one" ;-) I took the time to track down what caused a breakage - in an "illegal binary driver" (not against the law here, though defamation certainly is...) no less. And contacted the vendor (separately). Other people on desktop machines with an ATI card using the fglrx driver may have been interested to know that they can't do the benchmarking some people here on lkml and -mm are asking for with a current 2.6.23 git kernel, hence my post. Martin's cleanup patch is good and I never claimed otherwise, I just said the comment on the commit was a bad call (as there are users of that interface). Certainly ATI should fix their dodgy drivers. That's been the cry of the community for a long time... -- Matt - 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: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On 7/31/07, Jacob Braun <[EMAIL PROTECTED]> wrote: > On 7/30/07, kriko <[EMAIL PROTECTED]> wrote: > > I would try the new cfs how it performs, but it seems that nvidia drivers > > doesn't compile successfully under 2.6.23-rc1. > > http://files.myopera.com/kriko/files/nvidia-installer.log > > > > If someone has the solution, please share. > > There is a patch for the nvidia drivers here: > http://bugs.gentoo.org/attachment.cgi?id=125959 The ATI drivers (current 8.39.4) were broken by commit e21ea246bce5bb93dd822de420172ec280aed492 Author: Martin Schwidefsky <[EMAIL PROTECTED]> Bad call on the "nobody was using these", Martin :( -- Matt - 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: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On 7/31/07, Jacob Braun [EMAIL PROTECTED] wrote: On 7/30/07, kriko [EMAIL PROTECTED] wrote: I would try the new cfs how it performs, but it seems that nvidia drivers doesn't compile successfully under 2.6.23-rc1. http://files.myopera.com/kriko/files/nvidia-installer.log If someone has the solution, please share. There is a patch for the nvidia drivers here: http://bugs.gentoo.org/attachment.cgi?id=125959 The ATI drivers (current 8.39.4) were broken by commit e21ea246bce5bb93dd822de420172ec280aed492 Author: Martin Schwidefsky [EMAIL PROTECTED] Bad call on the nobody was using these, Martin :( -- Matt - 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: [ck] Re: SD still better than CFS for 3d ?
On 7/31/07, Roland Dreier [EMAIL PROTECTED] wrote: Fuck you Martin! I think you meant to yell at Matthew, not Martin ;) What's amusing about this is he's yelling at me for something I didn't do, can't even get my name right, and has the audacity to claim that *I* am the one looking like a fool! While we're descending into primary school theatrics, may I just say takes one to know one ;-) I took the time to track down what caused a breakage - in an illegal binary driver (not against the law here, though defamation certainly is...) no less. And contacted the vendor (separately). Other people on desktop machines with an ATI card using the fglrx driver may have been interested to know that they can't do the benchmarking some people here on lkml and -mm are asking for with a current 2.6.23 git kernel, hence my post. Martin's cleanup patch is good and I never claimed otherwise, I just said the comment on the commit was a bad call (as there are users of that interface). Certainly ATI should fix their dodgy drivers. That's been the cry of the community for a long time... -- Matt - 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: [ck] Re: Linus 2.6.23-rc1
On 7/30/07, Linus Torvalds <[EMAIL PROTECTED]> wrote: > For example, how hard is it for people to just admit that CFS actually > does better than SD on a number of things? Including very much on the > desktop. Actually in benchmarks Ingo has quoted, SD was better on the desktop (by a small margin). CFS is still a bit bursty, though it has significantly improved with age. I know, I did those benchmarks. That being said, I'm really glad to see CFS in your git tree because the new framework around it really improves the readability of the code, and actually makes it easier to start experimenting with scheduler improvements from an entire scheduler like SD to minor bits like priorities. I have one concern - my benchmarking took load average as the common denominator and CFS alters the way the load average is calculated, so perhaps it wasn't a fair comparison. That being said, they still showed CFS could scale very well and SD did not, so considering we're dealing with everything from wristwatches to BlueGene/L I believe the right choice was made. Those arguing for the 2% improvement that SD would give them in their environment would be better off a) helping port SD to the new scheduler framework b) assisting Ingo in improving CFS to meet/exceed their requirements c) giving practical assistance to anyone doing either of the above I'm re-learning git and using my Copious Spare Time (tm) to do what I can - but I have to admit I'm really in over my head. But hey, if Jeff Garzik can do it, so can I. I remember when he couldn't grok C & now he's got control over all our data :-) -- Matt - 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: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On 7/30/07, John <[EMAIL PROTECTED]> wrote: > I understand that, I was just wondering if the FPS scales the same natively > vs. Wine as I typically only run native games. I have been hesitant to move > over to CFS due to reports of 3D issues and wanted to see if you had numbers > in regards to CFS vs. SD. John, the numbers Ingo makes and the numbers you make will no doubt be different (unless by some fantastic freak of nature you both have identical systems). Take this opportunity to do this testing yourself so in case there is some improvement to make, it can be done for 2.6.23. Nobody can benchmark your system but you. Remember to set CONFIG_HZ to 1000 -- Matt - 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: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On 7/30/07, John [EMAIL PROTECTED] wrote: I understand that, I was just wondering if the FPS scales the same natively vs. Wine as I typically only run native games. I have been hesitant to move over to CFS due to reports of 3D issues and wanted to see if you had numbers in regards to CFS vs. SD. John, the numbers Ingo makes and the numbers you make will no doubt be different (unless by some fantastic freak of nature you both have identical systems). Take this opportunity to do this testing yourself so in case there is some improvement to make, it can be done for 2.6.23. Nobody can benchmark your system but you. Remember to set CONFIG_HZ to 1000 -- Matt - 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: [ck] Re: Linus 2.6.23-rc1
On 7/30/07, Linus Torvalds [EMAIL PROTECTED] wrote: For example, how hard is it for people to just admit that CFS actually does better than SD on a number of things? Including very much on the desktop. Actually in benchmarks Ingo has quoted, SD was better on the desktop (by a small margin). CFS is still a bit bursty, though it has significantly improved with age. I know, I did those benchmarks. That being said, I'm really glad to see CFS in your git tree because the new framework around it really improves the readability of the code, and actually makes it easier to start experimenting with scheduler improvements from an entire scheduler like SD to minor bits like priorities. I have one concern - my benchmarking took load average as the common denominator and CFS alters the way the load average is calculated, so perhaps it wasn't a fair comparison. That being said, they still showed CFS could scale very well and SD did not, so considering we're dealing with everything from wristwatches to BlueGene/L I believe the right choice was made. Those arguing for the 2% improvement that SD would give them in their environment would be better off a) helping port SD to the new scheduler framework b) assisting Ingo in improving CFS to meet/exceed their requirements c) giving practical assistance to anyone doing either of the above I'm re-learning git and using my Copious Spare Time (tm) to do what I can - but I have to admit I'm really in over my head. But hey, if Jeff Garzik can do it, so can I. I remember when he couldn't grok C now he's got control over all our data :-) -- Matt - 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: [ck] Re: Linus 2.6.23-rc1
On 7/28/07, Linus Torvalds <[EMAIL PROTECTED]> wrote: > People who think SD was "perfect" were simply ignoring reality. Sadly, > that seemed to include Con too, which was one of the main reasons that I > never ended entertaining the notion of merging SD for very long at all: > Con ended up arguing against people who reported problems, rather than > trying to work with them. Not even Con thought SD was perfect, so this is being more than a little dishonest. One of his parting comments on the ck list was a list of things that could be fixed/improved. My experience is vastly different to yours, perhaps because I have been subscribed to his mailing list for many years (too many to count) and have run his patchset in various environments in that period - and you have not. Con was always very helpful to people experiencing problems and did in fact work with them to get them resolved. The list is web-archived so everyone is free to go see that for themselves. He also tried to get others interested and involved in kernel development at large. SD itself went through 46 revisions because of things people encountered using it, and it would have been more still considering what Con had in the works had he not been pushed out. I can see how on LKML your viewpoint differs, though to be fair in my recollection there was only one person Con argued with, and that man is a belligerent troll. Its my honest opinion that the problems that troll encountered were completely made up, which is backed by the evidence that no-one else had encountered or indeed could even reproduce them. I recall Con himself catching the troll out in a lie-based "proof" on one occasion. I'll hunt gmane for the link as I believe people like that need to be exposed and stopped. There certainly was a lot of hot air and handwaving, and now that one other tiny portion of Con's work has been raised its still going on. Its interesting that the same cycle repeats even when Con is no longer involved, which proves Con could not have been the issue. I'm sorry you in particular haven't been able to have the same experience with Con as so many others have, especially considering who you are and the weight your words have. You've lost a really great asset and aren't even aware of it. That's really sad for everyone. (fwiw the -ck list did a lot of the testing for CFS recently, and over the years various other things too. Generally a good bunch of folks keen to try anything to make their Linux experience better. And definitely devoid of these petty politics and egos that are plagueing other Linux-related lists. You've not only lost Con, but perhaps one of the better testbeds also). -- Matt - 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: [ck] Re: Linus 2.6.23-rc1
On 7/28/07, Linus Torvalds [EMAIL PROTECTED] wrote: People who think SD was perfect were simply ignoring reality. Sadly, that seemed to include Con too, which was one of the main reasons that I never ended entertaining the notion of merging SD for very long at all: Con ended up arguing against people who reported problems, rather than trying to work with them. Not even Con thought SD was perfect, so this is being more than a little dishonest. One of his parting comments on the ck list was a list of things that could be fixed/improved. My experience is vastly different to yours, perhaps because I have been subscribed to his mailing list for many years (too many to count) and have run his patchset in various environments in that period - and you have not. Con was always very helpful to people experiencing problems and did in fact work with them to get them resolved. The list is web-archived so everyone is free to go see that for themselves. He also tried to get others interested and involved in kernel development at large. SD itself went through 46 revisions because of things people encountered using it, and it would have been more still considering what Con had in the works had he not been pushed out. I can see how on LKML your viewpoint differs, though to be fair in my recollection there was only one person Con argued with, and that man is a belligerent troll. Its my honest opinion that the problems that troll encountered were completely made up, which is backed by the evidence that no-one else had encountered or indeed could even reproduce them. I recall Con himself catching the troll out in a lie-based proof on one occasion. I'll hunt gmane for the link as I believe people like that need to be exposed and stopped. There certainly was a lot of hot air and handwaving, and now that one other tiny portion of Con's work has been raised its still going on. Its interesting that the same cycle repeats even when Con is no longer involved, which proves Con could not have been the issue. I'm sorry you in particular haven't been able to have the same experience with Con as so many others have, especially considering who you are and the weight your words have. You've lost a really great asset and aren't even aware of it. That's really sad for everyone. (fwiw the -ck list did a lot of the testing for CFS recently, and over the years various other things too. Generally a good bunch of folks keen to try anything to make their Linux experience better. And definitely devoid of these petty politics and egos that are plagueing other Linux-related lists. You've not only lost Con, but perhaps one of the better testbeds also). -- Matt - 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: [ck] Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]
On 7/26/07, Ingo Molnar <[EMAIL PROTECTED]> wrote: > wrong, it's active on three of my boxes already :) But then again, i > never had these hangover problems. (not really expected with gigs of RAM > anyway) [...] > --- /etc/cron.daily/mlocate.cron.orig [...] mlocate by design doesn't thrash the cache as much. People using slocate (distros other than Redhat ;) are going to be hit worse. See http://carolina.mff.cuni.cz/~trmac/blog/mlocate/ updatedb by itself doesn't really bug me, its just that on occasion its still running at 7am which then doesn't assist my single spindle come swapin of the other apps! I'm considering getting one of the old ide drives out in the garage and shifting swap onto it. The swap prefetch patch has mainly assisted me in the "state A -> B -> A" scenario. A lot. -- Matt - 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: [ck] Re: RFT: updatedb morning after problem [was: Re: -mm merge plans for 2.6.23]
On 7/26/07, Ingo Molnar [EMAIL PROTECTED] wrote: wrong, it's active on three of my boxes already :) But then again, i never had these hangover problems. (not really expected with gigs of RAM anyway) [...] --- /etc/cron.daily/mlocate.cron.orig [...] mlocate by design doesn't thrash the cache as much. People using slocate (distros other than Redhat ;) are going to be hit worse. See http://carolina.mff.cuni.cz/~trmac/blog/mlocate/ updatedb by itself doesn't really bug me, its just that on occasion its still running at 7am which then doesn't assist my single spindle come swapin of the other apps! I'm considering getting one of the old ide drives out in the garage and shifting swap onto it. The swap prefetch patch has mainly assisted me in the state A - B - A scenario. A lot. -- Matt - 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: [ck] Re: -mm merge plans for 2.6.23
On 7/26/07, Ray Lee <[EMAIL PROTECTED]> wrote: > Yeah, I know about inotify, but it doesn't scale. Yeah, the nonrecursive behaviour is a bugger. Also I found it helped to queue operations in userspace and execute periodically rather than trying to execute on every single notification. Worked well for indexing, for virus scanning though you'd want to do some risk analysis. It'd be nice to have a filesystem that handled that sort of thing internally *cough*winfs*cough*. That was my hope for reiserfs a very long time ago with its pluggable fs modules feature. -- Matt - 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: [ck] Re: -mm merge plans for 2.6.23
On 7/26/07, Ray Lee <[EMAIL PROTECTED]> wrote: I'd just like updatedb to amortize its work better. If we had some way to track all filesystem events, updatedb could keep a live and accurate index on the filesystem. And this isn't just updatedb that wants that, beagle and tracker et al also want to know filesystem events so that they can index the documents themselves as well as the metadata. And if they do it live, that spreads the cost out, including the VM pressure. We already have this, its called inotify (and if I'm not mistaken, beagle already uses it). Several years ago when it was still a little flakey patch, I built a custom filesystem indexer into an enterprise search engine using it (I needed to pull apart Unix mbox files). The only trouble of course is the action is triggered immediately, which may not always be ideal (but that's a userspace problem) -- Matt - 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: [ck] Re: -mm merge plans for 2.6.23
On 7/25/07, Nick Piggin <[EMAIL PROTECTED]> wrote: Not to say that neither fix some problems, but for such conceptually big changes, it should take a little more effort than a constructed test case and no consideration of the alternatives to get it merged. Swap Prefetch has existed since September 5, 2005. Please Nick, enlighten us all with your "alternatives" which have been offered (in practical, not theoretical form) in the past 23 months, along with their non-constructed benchmarks proving their case and the hordes of happy users and kernel developers who have tested them out the wazoo and given their backing. Or just take a nice steaming jug of STFU. -- Matt - 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: [ck] Re: -mm merge plans for 2.6.23
On 7/25/07, Nick Piggin <[EMAIL PROTECTED]> wrote: I'm not saying that we can't try to tackle that problem, but first of all you have a really nice narrow problem where updatedb seems to be causing the kernel to completely do the wrong thing. So we start on that. updatedb isn't the only problem, its just an obvious one. I like the idea of looking into the vfs for this and other one-shot applications (rather than looking at updatedb itself specifically) Many modern applications have a lot of open file handles. For example, I just fired up my usual audio player and sys/fs/file-nr showed another 600 open files (funnily enough, I have roughly that many audio files :) I'm not exactly sure what happens when this one gets swapped out for whatever reason (firefox/java/vmware/etc chews ram, updatedb, whatever) but I'm fairly confident what happens between kswapd and the vfs and whatever else we're caching is not optimal come time for this process to context-switch back in. We're not running a highly-optimised number-crunching scientific app on desktops, we're running a full herd of poorly-coded hogs simultaneously through smaller pens. I don't think anyone is trying to claim that swap prefetch is the be all and end all of this problem's solution, however without it the effects are an order of magnitude worse (I've cited numbers elsewhere, as have several others); its relatively non-intrusive (600+ lines of the 755 changed ones are self-contained), is compile and runtime selectable, and still has a maintainer now that Con has retired. If there was a better solution, it should have been developed sometime in the past 23 months that swap prefetch has addressed it. That's how we got rmap versus aa, and so on. But nobody chose to do so, and continuing to hold out on merging it on the promise of vapourware is ridiculous. That has never been the way linux kernel development has operated. -- Matt - 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: [ck] Re: -mm merge plans for 2.6.23
On 7/25/07, Nick Piggin [EMAIL PROTECTED] wrote: I'm not saying that we can't try to tackle that problem, but first of all you have a really nice narrow problem where updatedb seems to be causing the kernel to completely do the wrong thing. So we start on that. updatedb isn't the only problem, its just an obvious one. I like the idea of looking into the vfs for this and other one-shot applications (rather than looking at updatedb itself specifically) Many modern applications have a lot of open file handles. For example, I just fired up my usual audio player and sys/fs/file-nr showed another 600 open files (funnily enough, I have roughly that many audio files :) I'm not exactly sure what happens when this one gets swapped out for whatever reason (firefox/java/vmware/etc chews ram, updatedb, whatever) but I'm fairly confident what happens between kswapd and the vfs and whatever else we're caching is not optimal come time for this process to context-switch back in. We're not running a highly-optimised number-crunching scientific app on desktops, we're running a full herd of poorly-coded hogs simultaneously through smaller pens. I don't think anyone is trying to claim that swap prefetch is the be all and end all of this problem's solution, however without it the effects are an order of magnitude worse (I've cited numbers elsewhere, as have several others); its relatively non-intrusive (600+ lines of the 755 changed ones are self-contained), is compile and runtime selectable, and still has a maintainer now that Con has retired. If there was a better solution, it should have been developed sometime in the past 23 months that swap prefetch has addressed it. That's how we got rmap versus aa, and so on. But nobody chose to do so, and continuing to hold out on merging it on the promise of vapourware is ridiculous. That has never been the way linux kernel development has operated. -- Matt - 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: [ck] Re: -mm merge plans for 2.6.23
On 7/25/07, Nick Piggin [EMAIL PROTECTED] wrote: Not to say that neither fix some problems, but for such conceptually big changes, it should take a little more effort than a constructed test case and no consideration of the alternatives to get it merged. Swap Prefetch has existed since September 5, 2005. Please Nick, enlighten us all with your alternatives which have been offered (in practical, not theoretical form) in the past 23 months, along with their non-constructed benchmarks proving their case and the hordes of happy users and kernel developers who have tested them out the wazoo and given their backing. Or just take a nice steaming jug of STFU. -- Matt - 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: [ck] Re: -mm merge plans for 2.6.23
On 7/26/07, Ray Lee [EMAIL PROTECTED] wrote: I'd just like updatedb to amortize its work better. If we had some way to track all filesystem events, updatedb could keep a live and accurate index on the filesystem. And this isn't just updatedb that wants that, beagle and tracker et al also want to know filesystem events so that they can index the documents themselves as well as the metadata. And if they do it live, that spreads the cost out, including the VM pressure. We already have this, its called inotify (and if I'm not mistaken, beagle already uses it). Several years ago when it was still a little flakey patch, I built a custom filesystem indexer into an enterprise search engine using it (I needed to pull apart Unix mbox files). The only trouble of course is the action is triggered immediately, which may not always be ideal (but that's a userspace problem) -- Matt - 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: [ck] Re: -mm merge plans for 2.6.23
On 7/26/07, Ray Lee [EMAIL PROTECTED] wrote: Yeah, I know about inotify, but it doesn't scale. Yeah, the nonrecursive behaviour is a bugger. Also I found it helped to queue operations in userspace and execute periodically rather than trying to execute on every single notification. Worked well for indexing, for virus scanning though you'd want to do some risk analysis. It'd be nice to have a filesystem that handled that sort of thing internally *cough*winfs*cough*. That was my hope for reiserfs a very long time ago with its pluggable fs modules feature. -- Matt - 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: [ck] Re: -mm merge plans for 2.6.23
On 7/24/07, Andrew Morton <[EMAIL PROTECTED]> wrote: The other consideration here is, as Nick points out, are the problems which people see this patch solving for them solveable in other, better ways? IOW, is this patch fixing up preexisting deficiencies post-facto? So let me get this straight - you don't want to merge swap prefetch which exists now and solves issues many people are seeing, and has been tested more than a gazillion other bits & pieces that do get merged - because it could be possible that in the future some other patch, which doesn't yet exist and nobody is working on, may solve the problem better? You know what, just release Linux 0.02 as 2.6.23 because, using your logic, everything that was merged since October 5, 1991 could be replaced by something better. Perhaps. So there's obviously no point having it there in the first place & there'll be untold savings in storage costs and compilation time for the kernel tree, also bandwidth for the mirror sites etc. in the mean time while we wait for the magic pixies to come and deliver the one true piece of code that cannot be improved upon. Well. The above, plus there's always a lot of stuff happening in MM land, and I haven't seen much in the way of enthusiasm from the usual MM developers. I haven't seen much in the way of enthusiasm from developers, period. People are tired of maintaining patches for years that never get merged into mainline because of totally bullshit reasons (usually amounting to NIH syndrome) -- Matt - 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: [ck] Re: -mm merge plans for 2.6.23
On 7/24/07, Andrew Morton [EMAIL PROTECTED] wrote: The other consideration here is, as Nick points out, are the problems which people see this patch solving for them solveable in other, better ways? IOW, is this patch fixing up preexisting deficiencies post-facto? So let me get this straight - you don't want to merge swap prefetch which exists now and solves issues many people are seeing, and has been tested more than a gazillion other bits pieces that do get merged - because it could be possible that in the future some other patch, which doesn't yet exist and nobody is working on, may solve the problem better? You know what, just release Linux 0.02 as 2.6.23 because, using your logic, everything that was merged since October 5, 1991 could be replaced by something better. Perhaps. So there's obviously no point having it there in the first place there'll be untold savings in storage costs and compilation time for the kernel tree, also bandwidth for the mirror sites etc. in the mean time while we wait for the magic pixies to come and deliver the one true piece of code that cannot be improved upon. Well. The above, plus there's always a lot of stuff happening in MM land, and I haven't seen much in the way of enthusiasm from the usual MM developers. I haven't seen much in the way of enthusiasm from developers, period. People are tired of maintaining patches for years that never get merged into mainline because of totally bullshit reasons (usually amounting to NIH syndrome) -- Matt - 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: [ck] Re: -mm merge plans for 2.6.23
On 7/11/07, Andrew Morton <[EMAIL PROTECTED]> wrote: On Wed, 11 Jul 2007 11:02:56 +1000 "Matthew Hawkins" <[EMAIL PROTECTED]> wrote: Always interested. Please provide us more details on your usage and testing of that code. Amount of memory, workload, observed results, etc? My usual workstation has 1Gb of ram & 2Gb of swap (single partition - though in the past with multiple drives I would spread swap around the less-used disks & fiddle with the priority). Its acting as server for my home network too (so it has squid, cups, bind, dhcpd, apache, mysql & postgresql) but for the most part I'll have Listen playing music while I switch between Flock &/or Firefox, Thunderbird, and xvncviewer. On the odd occasion I'll fire up some game (gewled, actioncube, critical mass). Compiling these days has been mostly limited to kernels, I've been building mostly -ck and -cfs - keeping up-to-date and also doing some odd things (like patching the non-SD -ck stuff on top of CFS). Mainly just to get swap prefetch, but also not to lose skills since I'm out of the daily coding routine now. Anyhow with swap prefetch, applications that may have been sitting there idle for a while become responsive in the single-digit seconds rather than double-digit or worse. The same goes for a morning wakeup (ie after nightly cron jobs throw things out) and also after doing basically anything that wants memory, like benchmarking the various kernels I'm messing with or doing some local DB work or coding a memory leak into a web application running under apache ;) -- Matt - 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: [ck] Re: -mm merge plans for 2.6.23
On 7/11/07, Andrew Morton [EMAIL PROTECTED] wrote: On Wed, 11 Jul 2007 11:02:56 +1000 Matthew Hawkins [EMAIL PROTECTED] wrote: Always interested. Please provide us more details on your usage and testing of that code. Amount of memory, workload, observed results, etc? My usual workstation has 1Gb of ram 2Gb of swap (single partition - though in the past with multiple drives I would spread swap around the less-used disks fiddle with the priority). Its acting as server for my home network too (so it has squid, cups, bind, dhcpd, apache, mysql postgresql) but for the most part I'll have Listen playing music while I switch between Flock /or Firefox, Thunderbird, and xvncviewer. On the odd occasion I'll fire up some game (gewled, actioncube, critical mass). Compiling these days has been mostly limited to kernels, I've been building mostly -ck and -cfs - keeping up-to-date and also doing some odd things (like patching the non-SD -ck stuff on top of CFS). Mainly just to get swap prefetch, but also not to lose skills since I'm out of the daily coding routine now. Anyhow with swap prefetch, applications that may have been sitting there idle for a while become responsive in the single-digit seconds rather than double-digit or worse. The same goes for a morning wakeup (ie after nightly cron jobs throw things out) and also after doing basically anything that wants memory, like benchmarking the various kernels I'm messing with or doing some local DB work or coding a memory leak into a web application running under apache ;) -- Matt - 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] OOM killer API (was: [PATCH] VM fix for 2.4.0-test9 & OOM handler)
On 2000-10-11 19:53:50 -0700, [EMAIL PROTECTED] wrote: > On other machines I'd set RLIMIT_DATA and my OOM problems went away, > but on linux this didn't work RLIMIT_DATA appears to only be checked for aout format executables. Looking at the 2.4.0-test10pre1 sources for fs/binfmt_aout.c and fs/binfmt_elf.c you'll note the difference in load_aout_binary() and load_elf_binary(), both just above the comment of "OK, This is the point of no return" Does putting a similar check to the aout one make sense for ELF? I'm just trying to avoid Rik having to pull his hair out implementing a system that conceptually already exists in the kernel (nasty processes being terminated before they do some damage). Especially when that existing system is far more configurable. Cheers, -- Matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] OOM killer API (was: [PATCH] VM fix for 2.4.0-test9 & OOM handler)
On 2000-10-11 11:45:06 -0400, Bruce A. Locke wrote: > This manpage shows me functions and structs. What were you expecting from the system call section of the Linux Programmer's Manual? Dancing girls? (h...) > I'm assuming you want these used by the offending program or the shell > under which the program is being called. That's usually what happens. > In the first case, a person might not have source to the program and > if thats the case, it doesn't help much. Closed-source software is *so* 20th century... ;-) Anyway, when run from the shell it'll inherit its parent's limits (which leads to your next question...) > And in the second case, if the shell sets it, does it affect children > of a process (aka fork()'d)? Certainly. Maybe if more distributions took Debian's stance and set the default limits so anal that you frequently can't even read email let alone recompile the kernel without getting the process terminated for tripping one limit or another, then more people would know this functionality exists and set the limits more appropriately. -- Matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] OOM killer API (was: [PATCH] VM fix for 2.4.0-test9 & OOM handler)
On 2000-10-11 12:48:54 -0400, Andrew Pimlott wrote: > No way should a desktop user be responsible for micro-managing the > resource usage of his applications. That's right. The systems administrator should, and will set appropriate limits for users on his/her system that apply from login. This is how the systems I first used were configured (lucky me had a damn fine sysadmin), and so this is how I configure mine. > The only thing that knows what's right for Netscape is Netscape. I would disagree with this, I believe this is exactly the root of people's problems with Netscape (and the same theory should apply to other apps). The application doesn't know what's _right_ - it knows what it _wants_. Big difference. -- Matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] OOM killer API (was: [PATCH] VM fix for 2.4.0-test9 & OOM handler)
On 2000-10-11 10:33:39 -0400, Bruce A. Locke wrote: > > Your making the deadly assumption that all applications behave themselves > exactly the same all the time. Oops... netscape decided to freak out and > take up all your memory... guess its the admins fault. Yep, for not setting appropriate resource limits. man 2 setrlimit Of course, if its a kernel bug that causes it I think you're SOL ;) -- Matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
oops with 2.4.0-test9
Not sure how/when this one happened, ksymoops output as follows:
Unable to handle kernel paging request at virtual address 417df660
c014aff0
*pde =
Oops:
CPU:1
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00210206
eax: ebx: c780f3c0 ecx: 0002 edx: 417df660
esi: c780f421 edi: c17dff2d ebp: c32956e0 esp: d15f3efc
ds: 0018 es: 0018 ss: 0018
Process netstat (pid: 12589, stackpage=d15f3000)
Stack: fff4 d15f2000 c780f3c0 c32956e0 fffe c013c3c6 c32956e0 c780f3c0
d15f3f58 c32956e0 d15f3fa4 c013c859 c780f9c0 d15f3f58 0004
c83e2000 d15f3fa4 03f5 c013c0aa 0009 c83e200a
Call Trace: [] [] [] [] []
[]
Code: 66 83 3a 00 74 16 0f b7 4a 02 3b 4b 44 75 0d 8b 73 40 8b 7a
>>EIP; c014aff0<=
Trace; c013c3c6
Trace; c013c859
Trace; c013c0aa
Trace; c013d32c <__user_walk+3c/58>
Trace; c0130a2d
Trace; c010a6a3
Code; c014aff0
<_EIP>:
Code; c014aff0<=
0: 66 83 3a 00 cmpw $0x0,(%edx) <=
Code; c014aff4
4: 74 16 je 1c <_EIP+0x1c> c014b00c
Code; c014aff6
6: 0f b7 4a 02 movzwl 0x2(%edx),%ecx
Code; c014affa
a: 3b 4b 44 cmp0x44(%ebx),%ecx
Code; c014affd
d: 75 0d jne1c <_EIP+0x1c> c014b00c
Code; c014afff
f: 8b 73 40 mov0x40(%ebx),%esi
Code; c014b002
12: 8b 7a 00 mov 0x0(%edx),%edi
--
* Matthew Hawkins <[EMAIL PROTECTED]> :(){ :|:&};:
** Information Specialist, tSA Group Pty. Ltd. Ph: +61 2 6257 7111
*** 1 Hall Street, Lyneham ACT 2602 Australia. Fx: +61 2 6257 7311
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] OOM killer API (was: [PATCH] VM fix for 2.4.0-test9 & OOM handler)
On 2000-10-11 09:45:30 -0500, Jesse Pollard wrote:
> Until user memory resource quotas are included in the kernel, there will be
> nothing else that can be done. Even with resource quotas, if the total of
> active users exceeds the resource then the same/equivalent situation occurs.
So setrlimit() with RLIMIT_DATA, RLIMIT_STACK, RLIMIT_RSS,
RLIMIT_MEMLOCK, RLIMIT_AS et al is a null op?
If so, I wish to register a complaint ;-)
--
* Matthew Hawkins <[EMAIL PROTECTED]> :(){ :|:&};:
** Information Specialist, tSA Group Pty. Ltd. Ph: +61 2 6257 7111
*** 1 Hall Street, Lyneham ACT 2602 Australia. Fx: +61 2 6257 7311
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] OOM killer API (was: [PATCH] VM fix for 2.4.0-test9 & OOM handler)
Heh.. now all we need is some smart-arse to make something similar to apply to the _entire_ VM subsystem, and both Rik and Andrea can be happy ;) Seriously, am I missing something obvious or is it far simpler just to keel over and die if the system goes OOM? I mean, seriously, if the administrator lets it get to that state then he/she/it deserves a dead system. It's akin to having your car run out of petrol - you don't start shooting passengers because their extra load made the engine chew more. You pack up your kitty and go to the nearest petrol station and buy more, plug it into the car then learn from the experience so this fringe case of it happening doesn't happen again. I don't really see much difference between a car going "OOP" and a computer going OOM. Should we start deleting files according to some randomly-chosen heueristic if a filesystem goes "OOS" ? -- Matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] OOM killer API (was: [PATCH] VM fix for 2.4.0-test9 OOM handler)
Heh.. now all we need is some smart-arse to make something similar to apply to the _entire_ VM subsystem, and both Rik and Andrea can be happy ;) Seriously, am I missing something obvious or is it far simpler just to keel over and die if the system goes OOM? I mean, seriously, if the administrator lets it get to that state then he/she/it deserves a dead system. It's akin to having your car run out of petrol - you don't start shooting passengers because their extra load made the engine chew more. You pack up your kitty and go to the nearest petrol station and buy more, plug it into the car then learn from the experience so this fringe case of it happening doesn't happen again. I don't really see much difference between a car going "OOP" and a computer going OOM. Should we start deleting files according to some randomly-chosen heueristic if a filesystem goes "OOS" ? -- Matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] OOM killer API (was: [PATCH] VM fix for 2.4.0-test9 OOM handler)
On 2000-10-11 09:45:30 -0500, Jesse Pollard wrote:
Until user memory resource quotas are included in the kernel, there will be
nothing else that can be done. Even with resource quotas, if the total of
active users exceeds the resource then the same/equivalent situation occurs.
So setrlimit() with RLIMIT_DATA, RLIMIT_STACK, RLIMIT_RSS,
RLIMIT_MEMLOCK, RLIMIT_AS et al is a null op?
If so, I wish to register a complaint ;-)
--
* Matthew Hawkins [EMAIL PROTECTED] :(){ :|:};:
** Information Specialist, tSA Group Pty. Ltd. Ph: +61 2 6257 7111
*** 1 Hall Street, Lyneham ACT 2602 Australia. Fx: +61 2 6257 7311
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
oops with 2.4.0-test9
Not sure how/when this one happened, ksymoops output as follows:
Unable to handle kernel paging request at virtual address 417df660
c014aff0
*pde =
Oops:
CPU:1
EIP:0010:[c014aff0]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00210206
eax: ebx: c780f3c0 ecx: 0002 edx: 417df660
esi: c780f421 edi: c17dff2d ebp: c32956e0 esp: d15f3efc
ds: 0018 es: 0018 ss: 0018
Process netstat (pid: 12589, stackpage=d15f3000)
Stack: fff4 d15f2000 c780f3c0 c32956e0 fffe c013c3c6 c32956e0 c780f3c0
d15f3f58 c32956e0 d15f3fa4 c013c859 c780f9c0 d15f3f58 0004
c83e2000 d15f3fa4 03f5 c013c0aa 0009 c83e200a
Call Trace: [c013c3c6] [c013c859] [c013c0aa] [c013d32c] [c0130a2d]
[c010a6a3]
Code: 66 83 3a 00 74 16 0f b7 4a 02 3b 4b 44 75 0d 8b 73 40 8b 7a
EIP; c014aff0 proc_lookup+30/a0 =
Trace; c013c3c6 real_lookup+76/11c
Trace; c013c859 path_walk+27d/864
Trace; c013c0aa getname+5a/98
Trace; c013d32c __user_walk+3c/58
Trace; c0130a2d sys_access+8d/128
Trace; c010a6a3 system_call+33/38
Code; c014aff0 proc_lookup+30/a0
_EIP:
Code; c014aff0 proc_lookup+30/a0 =
0: 66 83 3a 00 cmpw $0x0,(%edx) =
Code; c014aff4 proc_lookup+34/a0
4: 74 16 je 1c _EIP+0x1c c014b00c proc_lookup+4c/a0
Code; c014aff6 proc_lookup+36/a0
6: 0f b7 4a 02 movzwl 0x2(%edx),%ecx
Code; c014affa proc_lookup+3a/a0
a: 3b 4b 44 cmp0x44(%ebx),%ecx
Code; c014affd proc_lookup+3d/a0
d: 75 0d jne1c _EIP+0x1c c014b00c proc_lookup+4c/a0
Code; c014afff proc_lookup+3f/a0
f: 8b 73 40 mov0x40(%ebx),%esi
Code; c014b002 proc_lookup+42/a0
12: 8b 7a 00 mov0x0(%edx),%edi
--
* Matthew Hawkins [EMAIL PROTECTED] :(){ :|:};:
** Information Specialist, tSA Group Pty. Ltd. Ph: +61 2 6257 7111
*** 1 Hall Street, Lyneham ACT 2602 Australia. Fx: +61 2 6257 7311
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] OOM killer API (was: [PATCH] VM fix for 2.4.0-test9 OOM handler)
On 2000-10-11 10:33:39 -0400, Bruce A. Locke wrote: Your making the deadly assumption that all applications behave themselves exactly the same all the time. Oops... netscape decided to freak out and take up all your memory... guess its the admins fault. Yep, for not setting appropriate resource limits. man 2 setrlimit Of course, if its a kernel bug that causes it I think you're SOL ;) -- Matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] OOM killer API (was: [PATCH] VM fix for 2.4.0-test9 OOM handler)
On 2000-10-11 12:48:54 -0400, Andrew Pimlott wrote: No way should a desktop user be responsible for micro-managing the resource usage of his applications. That's right. The systems administrator should, and will set appropriate limits for users on his/her system that apply from login. This is how the systems I first used were configured (lucky me had a damn fine sysadmin), and so this is how I configure mine. The only thing that knows what's right for Netscape is Netscape. I would disagree with this, I believe this is exactly the root of people's problems with Netscape (and the same theory should apply to other apps). The application doesn't know what's _right_ - it knows what it _wants_. Big difference. -- Matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] OOM killer API (was: [PATCH] VM fix for 2.4.0-test9 OOM handler)
On 2000-10-11 11:45:06 -0400, Bruce A. Locke wrote: This manpage shows me functions and structs. What were you expecting from the system call section of the Linux Programmer's Manual? Dancing girls? (h...) I'm assuming you want these used by the offending program or the shell under which the program is being called. That's usually what happens. In the first case, a person might not have source to the program and if thats the case, it doesn't help much. Closed-source software is *so* 20th century... ;-) Anyway, when run from the shell it'll inherit its parent's limits (which leads to your next question...) And in the second case, if the shell sets it, does it affect children of a process (aka fork()'d)? Certainly. Maybe if more distributions took Debian's stance and set the default limits so anal that you frequently can't even read email let alone recompile the kernel without getting the process terminated for tripping one limit or another, then more people would know this functionality exists and set the limits more appropriately. -- Matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] OOM killer API (was: [PATCH] VM fix for 2.4.0-test9 OOM handler)
On 2000-10-11 19:53:50 -0700, [EMAIL PROTECTED] wrote: On other machines I'd set RLIMIT_DATA and my OOM problems went away, but on linux this didn't work RLIMIT_DATA appears to only be checked for aout format executables. Looking at the 2.4.0-test10pre1 sources for fs/binfmt_aout.c and fs/binfmt_elf.c you'll note the difference in load_aout_binary() and load_elf_binary(), both just above the comment of "OK, This is the point of no return" Does putting a similar check to the aout one make sense for ELF? I'm just trying to avoid Rik having to pull his hair out implementing a system that conceptually already exists in the kernel (nasty processes being terminated before they do some damage). Especially when that existing system is far more configurable. Cheers, -- Matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: What is up with Redhat 7.0?
On Tue, 03 Oct 2000 02:37:26 -0400 Dmitri Pogosyan <[EMAIL PROTECTED]> wrote: > Well, being just an end customer, I would not judge technical quality > of RedHat packages [...] With that kind of general attitude, I suggest you stay well clear of used car salesmen (in particular). > I guess you were asking your questions in a language similar to the > one you used in your message here :( I'm not sure what you mean by asking questions, since submitting bug reports generally involves providing some sample erroneous output or proof of erroneus behaviour, and hopefully a patch (or patches) to fix it. To some extent it even involves being active on relevent lists, helping others with their problems you've got a fix for, and getting help from others who have fixed things you haven't. I don't think I'd be too wrong in saying most people here are the same, and have done/do the above. Also through lack of use I've unfortunately lost my fluency in German and Japanese, so I'm stuck conversing in my native English (although I apologise if I let any local slang slip through, I'm happy to clarify off the list) -- Matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: What is up with Redhat 7.0?
On Tue, 03 Oct 2000 02:37:26 -0400 Dmitri Pogosyan [EMAIL PROTECTED] wrote: Well, being just an end customer, I would not judge technical quality of RedHat packages [...] With that kind of general attitude, I suggest you stay well clear of used car salesmen (in particular). I guess you were asking your questions in a language similar to the one you used in your message here :( I'm not sure what you mean by asking questions, since submitting bug reports generally involves providing some sample erroneous output or proof of erroneus behaviour, and hopefully a patch (or patches) to fix it. To some extent it even involves being active on relevent lists, helping others with their problems you've got a fix for, and getting help from others who have fixed things you haven't. I don't think I'd be too wrong in saying most people here are the same, and have done/do the above. Also through lack of use I've unfortunately lost my fluency in German and Japanese, so I'm stuck conversing in my native English (although I apologise if I let any local slang slip through, I'm happy to clarify off the list) -- Matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: What is up with Redhat 7.0?
On Mon, 2 Oct 2000 21:40:59 -0400, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Why didn't the package maintainer issue a formal release, if they really > thought it was the best thing for RedHat to be using Perhaps you're getting Redhat confused with Debian here. Redhat doesn't have package maintainers. It has 1,000 monkeys at 1,000 typewriters recreating the works of Shakespeare, a la "it was the best of times, it was the blurst of times" One reason I stopped running and recommending Redhat was the inferior quality of their packages. They'd ship half-complete, half-assed packages and it was concerned end-users who'd have to make their own RPMS and kindly make them available to the world, to fix the irritating stupid bugs in the default Redhat ones. Of course, some enlightened Redhat employee will no doubt tell me I should register bug reports about their packages through official channels blah blah blah which is no use when you do that and the bug reports are ignored for over six months while Redhat are off promoting themselves at one conference or another, arse-kissing for more shareholders while at the other end screwing over the people that put them into the position they could IPO in in the first place. There's noone responsible for a package, unlike Debian (the other extreme) where each package has a maintainer who is responsible for making sure that package is reliable, security-conscious and integrates well into the rest of the system. With RH you just submit bug reports to some tracking system and three revisions down the track somebody will get back from self-promotion at whatever conference and go "damn, there's a lot of bug reports, I might look at one or two then delete the rest" and maybe your bug is one of the lucky two, so you and the millions of other Redhat users don't have to manually fix it next time. That might not be quite how it works now (and for their sake, I hope not), but it sure looks that way from the outside, from the eyes of a former loyal customer. That, combined with the fact they somehow managed to get a hold of certain key kernel developers so stable linux kernel developments by their competitors don't get integrated into the stable kernel (eg, reiserfs & a better VM for 2.2, both sponsored in part or full by SuSE) really ticks me off as a person who cares more about a quality, useful Linux in general and not about generation of revenue for shareholders at the expense of all else. I'm not surprised Redhat 7.0 is full of bugs, everybody should know by now that you have to wait for 7.2 so the SuSE and Debian guys have time to fix some of the bugs in the initial release. BUGTRAQ is usually hard to ignore... Oh yeah, I posted these and a few other concerns not really worth repeating to this list for topic/breveties sake, to the appropriate channels @redhat three years ago and, surprise surprise, was ignored just like every other legitimate bug report or compalint. Maybe a public post when an obvious outcome of their problems they haven't addresed over this time becomes headlines might spur someone into action over there. I'd really really hate to see Redhat go under, which is the ultimate eventuality I feel if they continue down this course. Redhat do a lot of good things in other areas which is good for Linux as a whole. Unfortunately quality isn't one of them, neither is support. Erik, Bob, Mike.. guys.. please fix. For many people Redhat == Linux and we need to show that Linux == great, not Linux == mediocre. Make use of the community, eg Linuxcare might be a good choice to outsource support to so you can forget about that bit to some extent and concentrate on other bits. Just some suggestions, I'm trying to be constructive :) Cheers, -- Matt (speaking for myself, not my company) PS: Yes, Alan, I'm a paranoid loon, just like the many many other paranoid loons who have observed exactly the same things, said it out of concern for you and the other usually good guys there, and get labelled... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: More on 2.2.18pre2aa2
On 2000-09-11 09:22:23 -0400, Chris Mason wrote:
> Thanks Andrea, Andi, new patch is attached, with the warning messages
> removed. The first patch got munged somewhere between test machine and
> mailer, please don't use it.
I've been hammering this all day installing the relevent tools and
building win32 mozilla under vmware (the drives being 2Gb files on a
reiserfs partition). This partition also doubles as /home.
Very stable so far, and having Andrea's VM patches in (I usually didn't
put them in) has made a noticeable difference - xmms has rarely skipped
and things start faster and run smoother. Hopefully I'll see the same
(or better) results from Rik's new VM in 2.4 when that's released.
# free
total used free sharedbuffers cached
Mem:392792 390232 2560 0 25948 261484
-/+ buffers/cache: 102800 289992
Swap: 196548 0 196548
# vmstat 2
procs memoryswap io system cpu
r b w swpd free buff cache si sobibo incs us sy id
1 0 0 0 2412 26084 261496 0 0 817 454 922 17 40 44
1 0 0 0 2292 26204 261496 0 0 213 443 516 6 50 45
2 0 0 0 2244 26252 261496 0 0 0 0 439 367 13 38 49
1 0 0 0 2784 26016 261192 0 059 0 453 815 8 50 42
1 0 0 0 2420 26152 261420 0 03023 460 675 4 59 37
1 0 0 0 2252 26208 261532 0 015 0 445 465 5 55 40
3 0 0 0 2084 26252 261656 0 01819 450 446 4 56 40
3 0 0 0 2056 26280 261656 0 0 1 0 442 366 3 54 43
4 0 0 0 3012 25868 261108 0 018 0 443 423 9 45 46
2 0 0 0 2348 25932 261708 0 07519 463 703 6 51 44
FWIW the reiserfs partition is on a 30Gb IBM 75GXP attached to a Promise
ATA100 PCI controller. I have Andre's 2904 ide patch in. Nice
drive if you have to use IDE, and I have no complaints about the
controller either.
--
* Matthew Hawkins <[EMAIL PROTECTED]> :(){ :|:&};:
** Information Specialist, tSA Group Pty. Ltd. Ph: +61 2 6257 7111
*** 1 Hall Street, Lyneham ACT 2602 Australia. Fx: +61 2 6257 7311
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: More on 2.2.18pre2aa2
On 2000-09-11 09:22:23 -0400, Chris Mason wrote:
Thanks Andrea, Andi, new patch is attached, with the warning messages
removed. The first patch got munged somewhere between test machine and
mailer, please don't use it.
I've been hammering this all day installing the relevent tools and
building win32 mozilla under vmware (the drives being 2Gb files on a
reiserfs partition). This partition also doubles as /home.
Very stable so far, and having Andrea's VM patches in (I usually didn't
put them in) has made a noticeable difference - xmms has rarely skipped
and things start faster and run smoother. Hopefully I'll see the same
(or better) results from Rik's new VM in 2.4 when that's released.
# free
total used free sharedbuffers cached
Mem:392792 390232 2560 0 25948 261484
-/+ buffers/cache: 102800 289992
Swap: 196548 0 196548
# vmstat 2
procs memoryswap io system cpu
r b w swpd free buff cache si sobibo incs us sy id
1 0 0 0 2412 26084 261496 0 0 817 454 922 17 40 44
1 0 0 0 2292 26204 261496 0 0 213 443 516 6 50 45
2 0 0 0 2244 26252 261496 0 0 0 0 439 367 13 38 49
1 0 0 0 2784 26016 261192 0 059 0 453 815 8 50 42
1 0 0 0 2420 26152 261420 0 03023 460 675 4 59 37
1 0 0 0 2252 26208 261532 0 015 0 445 465 5 55 40
3 0 0 0 2084 26252 261656 0 01819 450 446 4 56 40
3 0 0 0 2056 26280 261656 0 0 1 0 442 366 3 54 43
4 0 0 0 3012 25868 261108 0 018 0 443 423 9 45 46
2 0 0 0 2348 25932 261708 0 07519 463 703 6 51 44
FWIW the reiserfs partition is on a 30Gb IBM 75GXP attached to a Promise
ATA100 PCI controller. I have Andre's 2904 ide patch in. Nice
drive if you have to use IDE, and I have no complaints about the
controller either.
--
* Matthew Hawkins [EMAIL PROTECTED] :(){ :|:};:
** Information Specialist, tSA Group Pty. Ltd. Ph: +61 2 6257 7111
*** 1 Hall Street, Lyneham ACT 2602 Australia. Fx: +61 2 6257 7311
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18pre2aa2 and patches for 2.2.18pre3
On 2000-09-07 22:39:55 +0100, Alan Cox wrote:
> > Andrea VM patches will be included in 2.2.18.
>
> We'll see
Something between bigmem and his big VM changes makes reiserfs
uncompilable. I stay with the stock VM and its only under significant
load that it falls over and starts messing with the smooth continuity of
X pointer movement and mp3 decoding.
Surely though I can't be the only person with an SMP system experiencing
the pointless cpu chewing while idle without Marcelo's sync_page_buffers()
fix? Again, Andrea's SMP patches are worth a look too as most of them are
so simple even I can see they make sense. No problems yet on a UP
system with them patched in either.
--
* Matthew Hawkins <[EMAIL PROTECTED]> :(){ :|:&};:
** Information Specialist, tSA Group Pty. Ltd. Ph: +61 2 6257 7111
*** 1 Hall Street, Lyneham ACT 2602 Australia. Fx: +61 2 6257 7311
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18pre2aa2 and patches for 2.2.18pre3
I'd like to advocate the inclusion of the majority of these patches of
Andrea's. I've been patching most of them in for a while now simply
because I've found my SMP system much more stable and useable.
Distinctly lacking from the 2.2.17 release was Marcelo Tosatti's age-old
1-character fix to sync_page_buffers() without which my system is unusable.
(namely, doing WRITEA in the call to ll_rw_block()). Andrea provides a
similar and cleaner implementation of the entire sync_page_buffers()
function which also works fine.
Debate the more ambitious patches he proposes all you like, all I care
about is the SMP fixes / improvements and the fact that I don't have to
put up with both cpu's going flat out even when the system is, from a
user's perspective, idle. I don't use initrd, have an AXP (worse luck),
use >2Gb files or LVM. Although having a 2.3 compatible LVM would not
go astray for a 2.2.x-lmp :)
*clink clink*
--
* Matthew Hawkins <[EMAIL PROTECTED]> :(){ :|:&};:
** Information Specialist, tSA Group Pty. Ltd. Ph: +61 2 6257 7111
*** 1 Hall Street, Lyneham ACT 2602 Australia. Fx: +61 2 6257 7311
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18pre2aa2 and patches for 2.2.18pre3
I'd like to advocate the inclusion of the majority of these patches of
Andrea's. I've been patching most of them in for a while now simply
because I've found my SMP system much more stable and useable.
Distinctly lacking from the 2.2.17 release was Marcelo Tosatti's age-old
1-character fix to sync_page_buffers() without which my system is unusable.
(namely, doing WRITEA in the call to ll_rw_block()). Andrea provides a
similar and cleaner implementation of the entire sync_page_buffers()
function which also works fine.
Debate the more ambitious patches he proposes all you like, all I care
about is the SMP fixes / improvements and the fact that I don't have to
put up with both cpu's going flat out even when the system is, from a
user's perspective, idle. I don't use initrd, have an AXP (worse luck),
use 2Gb files or LVM. Although having a 2.3 compatible LVM would not
go astray for a 2.2.x-lmp :)
*clink clink*
--
* Matthew Hawkins [EMAIL PROTECTED] :(){ :|:};:
** Information Specialist, tSA Group Pty. Ltd. Ph: +61 2 6257 7111
*** 1 Hall Street, Lyneham ACT 2602 Australia. Fx: +61 2 6257 7311
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18pre2aa2 and patches for 2.2.18pre3
On 2000-09-07 22:39:55 +0100, Alan Cox wrote:
Andrea VM patches will be included in 2.2.18.
We'll see
Something between bigmem and his big VM changes makes reiserfs
uncompilable. I stay with the stock VM and its only under significant
load that it falls over and starts messing with the smooth continuity of
X pointer movement and mp3 decoding.
Surely though I can't be the only person with an SMP system experiencing
the pointless cpu chewing while idle without Marcelo's sync_page_buffers()
fix? Again, Andrea's SMP patches are worth a look too as most of them are
so simple even I can see they make sense. No problems yet on a UP
system with them patched in either.
--
* Matthew Hawkins [EMAIL PROTECTED] :(){ :|:};:
** Information Specialist, tSA Group Pty. Ltd. Ph: +61 2 6257 7111
*** 1 Hall Street, Lyneham ACT 2602 Australia. Fx: +61 2 6257 7311
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
