[00:09] Bertl (~herbert@212.16.62.51) left irc: Quit: Bertl has no reason [00:09] Bertl (~herbert@MAIL.13thfloor.at) joined #vserver. [00:09] test [00:13] serving (~serving@213.186.190.120) joined #vserver. [00:16] Bertl (~herbert@MAIL.13thfloor.at) left irc: Quit: Bertl has no reason [00:16] Bertl (~herbert@212.16.62.51) joined #vserver. [00:17] test [00:18] Nick change: Bertl -> Bertl_zZ [00:18] Bertl_zZ (~herbert@212.16.62.51) left irc: Client Quit [01:39] hi [02:48] loger7 joined #vserver. [02:48] loger (~loger@213.159.117.2) left irc: Read error: Connection reset by peer [02:48] Nick change: loger7 -> loger [03:47] serving (~serving@213.186.190.120) left irc: Ping timeout: 513 seconds [04:29] newz (~newz@65.34.52.169) left irc: [04:32] Bertl (~herbert@212.16.62.51) joined #vserver. [04:50] Bertl: [04:51] hi! [04:51] hi! [04:55] whats up? [04:56] nothing new, and you? [04:56] any word on a 1.0 release date? [04:56] hrm, it's going good now [04:56] well I need some feedback on the non i386/x86_64 platforms ... [04:57] oh [04:57] hrm [04:57] would you say within a week? [04:58] well I don't know, mabe it takes longer to get feedback for some platforms ... [04:58] true [04:59] just wondering... [04:59] as I said several times, I can [05:00] you can what? :) [05:00] as I said several times, I depend on the testers ... [05:00] if there is nobody reporting back, I don't know anything ... [05:01] i tried to test O(1) but it appears both of my test installs are fubar'ed [05:01] so i need to re-install them [05:02] hmm explain foobar'ed ... [05:02] if you made a 1.0-test1 with rediffed ml / dl / O(1) patches I would test it on i386 and if that went fine I would install it on a production server of mine which is a pretty damn good real world test [05:02] fubar = fucked up beyond all repair [05:03] I know that, thanks, but what do you mean ... [05:03] oh, for some reason they are both booting up with root read only [05:03] i think something to do with running alex's patch on them... [05:04] maybe add 'rw' or remove 'ro' in the kernel command line? [05:04] i tried [05:04] i'm still messing with it, but that's the only reason I didn't test the O(1) patch yet [05:05] brb ... [05:05] Bertl (~herbert@212.16.62.51) left irc: Quit: Bertl has no reason [05:06] Bertl (~herbert@MAIL.13thfloor.at) joined #vserver. [05:06] and the usual stuff is working as expected? [05:07] the usual? [05:07] cq/cx/mq/ml/dl ... [05:07] i'm using that on 2.4.22-c17e on 2 production machines... no problems yet [05:07] for almost 5 days now [05:08] good to hear ... [05:08] now this is weird [05:08] mount reports / is mounted rw [05:08] but a 'touch tmp' says "Read-only file system" [05:09] use cat /proc/mounts instead of mount [05:09] really, the reason i'm asking the time is because i want to upgrade hardware in a few days and i'd like to do the kernel upgrade at the same time [05:09] yeah, rw in /proc/mounts too... [05:09] odd [05:09] no mount on /tmp ? [05:11] tmp is a filename [05:11] hmm /tmp should be a directory ... [05:11] hrm [05:12] it's anything, tmp was just the filename i used as an example [05:12] ie. touch any_filename [05:12] touch file [05:12] ... [05:12] i'm just doing a new install [05:13] redhat9 this time [05:13] others are 7.3 [05:34] CosmicRay (~jgoerzen@12.149.180.20) joined #vserver. [05:37] hi cosmic! [05:38] serving (~serving@213.186.189.101) joined #vserver. [05:38] hello bertl [05:38] 2.4.22-c17f [05:38] 8 days uptime [05:39] pfft :-) 20:41:46 up 156 days, 7:15, 1 user, load average: 0.12, 0.04, 0.01 [05:40] with c17f? [05:40] hmmm I'm not sure what ctx patch that was at... [05:40] hehe this is not a competition [05:41] shuri: I know :-) I'm proud of that, though, because that same machine used to crash on a weekly basis [05:41] I think it is plain ctx17 [05:41] the tg3 driver and ctx did not play well together [05:43] I'm running 18 vservers on there. 17 of them are Debian and one is SuSE :-) [05:46] 4 debians / 1 redhat / 1 suse / 1 slackware [05:46] I could never manage to get suse to install straight into the vserver [05:46] I had to install it on the metal on a different box, tar it up and copy it over [05:46] did you have to do that to? [05:46] yes [05:47] sucks to not have debootstrap :-) [05:47] same with slackware [05:47] really [05:47] I haven't used it in ages I guess :-) [05:47] hehe [05:48] I think the last time I used slackware was 1996 [05:49] dam [05:49] hehe [05:49] I switched to Debian :-) [05:50] so tell me about modern slackware [05:50] what makes it cool? [05:50] the fridge ;) [05:51] heh [05:59] HELP SET AUTO_RESPONSE [06:00] DESman (chris@62.26.112.254) joined #vserver. [06:00] hi [06:00] hi [06:00] you are working at this late time =) [06:00] early ... [06:01] ^^ or so [06:01] /usr/lib/vserver/vrsetup: can't open device /dev/vroot/7274: No such device or address [06:01] /usr/sbin/vserver: ulimit: cannot modify max user processes limit: Invalid argument [06:01] ls -la /dev/vroot/7274 [06:02] brw-r--r-- 1 root root 4, 0 Sep 17 14:54 /dev/vroot/7274 [06:02] it worked under 2.4.21 + ctx17a + vquota patch [06:02] but now with 2.4.22 and 17f not anymore [06:02] and now you used c17f without any other patch ... [06:03] you need the vr patch and you would benefit from the ulimit-unfix patch ... [06:04] http://vserver.13thfloor.at/Experimental/patch-2.4.22-ctx17a-vr0.13.diff.bz2 [06:04] http://vserver.13thfloor.at/Experimental/vr-tools-0.14.tar.bz2 [06:04] http://vserver.13thfloor.at/Experimental/patch-2.4.22-ctx17a-vr0.13.diff.bz2 <---- so this patch and then 17f ?! [06:05] first c17f, then the other patches ... [06:05] http://www.13thfloor.at/VServer/patches-2.4.22-c17/16_ulimit-unfix.diff.bz2 [06:07] ok so 2.4.22 then c17f, then vr0.13 then vr-tools then ulimit-unfix [06:08] vr-tools is no patch, but the rest is correct ... [06:08] k [06:12] patch -p1 < ../16_ulimit-unfix.diff [06:12] patching file kernel/sys.c [06:12] Hunk #1 succeeded at 1279 (offset 136 lines). [06:12] looks good ... [06:12] so ignore [06:12] ok [06:12] succeeded = succeeded [06:13] you are right ( how ever ) =) [06:33] ioctl: VROOT_SET_DEV: Device or resource busy [06:33] this is ok i think [06:33] depends .. it means that the vroot is already configured to something else ... [06:34] hmmm [06:34] each vserver context has its own /dev/vroot/xxx [06:34] and at each this message arrive [06:35] they dont hit each other [06:35] all configs are ok [06:35] show me the ls -la of two of them ... [06:36] ls -la 7012 [06:36] brw-r--r-- 1 root root 4, 0 Sep 16 15:12 7012 [06:36] vserver1:/dev/vroot# ls -la 7083 [06:36] brw-r--r-- 1 root root 4, 0 Sep 15 18:50 7083 [06:36] this is the _same_ device ... so the reply is as expected ... [06:36] i see so it sould have to be: [06:37] mknod /dev/vroot/$2 b 4 0 [06:37] mknod /dev/vroot/xxx b 4 0 [06:37] mknod /dev/vroot/xxx b 4 1 [06:37] mknod /dev/vroot/xxx b 4 2 [06:37] mknod /dev/vroot/xxx b 4 x [06:37] right ? [06:38] yes, but at most 254 devices are possible, and the default limit is 4 ... [06:38] ok [06:38] thank you [06:38] do you have a partition for each vserver? [06:38] yes lvm [06:40] ChuckD_zzz (~bug@144.137.122.238) left #vserver. [06:40] ok so i will have to reset all /dev/vroot to get it work whti b 4 x [06:42] if you want more than 4 devices, you have to either edit the kernel sources or specify the max_vroot= parameter ... [06:44] where to specify the max_vroot ? [06:45] either on kernel boot, or on module load .. depends on the vroot type (monolithic or module) [06:45] so kernel boot i always compile all into the kernel static [06:46] so i have to append max_vroot=200 for example to my lilo [06:46] if you have 200 lvm partitions, yes ... [06:46] no i don`t, but it wont hurt as i see [06:47] it will eat up kernel memory ... [06:47] ok thanks for hint! [06:51] CosmicRay (~jgoerzen@12.149.180.20) left #vserver (Client exiting). [07:05] herbert (~herbert@MAIL.13thfloor.at) joined #vserver. [07:06] test [07:06] test [07:20] 5C7O8L3O2R [07:21] red, orange, yellow, green, blue [07:24] thank you for your greate help Bertl! [07:24] no problem, everything working now? [07:25] it seems so, no errors or uncommon messages [07:25] if any occure, i will tell it [07:25] okay ... have fun! [07:26] thank you! [07:26] DESman (chris@62.26.112.254) left irc: [07:29] matta (matta@tektonic.net) left irc: Remote host closed the connection [07:33] test [07:36] herbert (~herbert@MAIL.13thfloor.at) left irc: Quit: leaving [07:50] Bertl_ (~herbert@MAIL.13thfloor.at) joined #vserver. [07:51] Bertl_ (~herbert@MAIL.13thfloor.at) left irc: Client Quit [07:51] Bertl_ (~herbert@MAIL.13thfloor.at) joined #vserver. [07:52] Bertl_ (~herbert@MAIL.13thfloor.at) left irc: Client Quit [07:52] Bertl_ (~herbert@MAIL.13thfloor.at) joined #vserver. [07:57] mdaur__ (mdaur@p509160A0.dip.t-dialin.net) joined #vserver. [07:58] test [08:01] Bertl_ (~herbert@MAIL.13thfloor.at) left irc: Quit: leaving [08:01] Bertl_ (~herbert@MAIL.13thfloor.at) joined #vserver. [08:03] test [08:03] Bertl_ (~herbert@MAIL.13thfloor.at) left irc: Client Quit [08:03] Nick change: Bertl -> Bertl_zZ [08:04] mdaur_ (mdaur@80.145.94.23) left irc: Ping timeout: 513 seconds [08:45] matta (matta@tektonic.net) joined #vserver. [10:19] dst (~dst@p4b23e3d4.np.schlund.de) left irc: Ping timeout: 483 seconds [11:15] ChuckD_zzz (~bug@144.137.122.238) joined #vserver. [11:33] dst (~dst@212.227.35.75) joined #vserver. [11:45] ChuckD_zzz (~bug@144.137.122.238) left #vserver. [12:04] mhepp (~mhepp@r72s22p13.home.nbox.cz) joined #vserver. [12:26] JonB (~jon@129.142.112.33) joined #vserver. [12:33] mdaur__ (mdaur@p509160A0.dip.t-dialin.net) left irc: Quit: cya [13:22] serving (~serving@213.186.189.101) left irc: Ping timeout: 513 seconds [13:37] mhepp (~mhepp@r72s22p13.home.nbox.cz) left irc: Read error: Connection reset by peer [13:38] mhepp (~mhepp@213.211.38.19) joined #vserver. [13:38] NZ|Egor (~sgarner@apollo.quattro.net.nz) joined #vserver. [13:39] http://bulk.fefe.de/scalability/ [14:32] stone (foobar@213.180.66.154) left irc: Ping timeout: 513 seconds [14:55] ccooke (~ccooke@public1-walt1-4-cust238.lond.broadband.ntl.com) joined #vserver. [16:17] serving (~serving@213.186.189.101) joined #vserver. [16:37] Nick change: noel- -> noel [16:46] Action: mhepp is away: I am not here... [17:22] mhepp (~mhepp@213.211.38.19) left irc: Remote host closed the connection [17:47] ChuckD_zzz (~bug@CPE-144-137-122-238.nsw.bigpond.net.au) joined #vserver. [17:48] ChuckD_zzz (~bug@CPE-144-137-122-238.nsw.bigpond.net.au) left #vserver. [17:50] mhepp (~mhepp@213.211.38.19) joined #vserver. [17:51] mhepp (~mhepp@213.211.38.19) left irc: Remote host closed the connection [17:51] mhepp (~mhepp@r72s22p13.home.nbox.cz) joined #vserver. [18:02] serving (~serving@213.186.189.101) left irc: Ping timeout: 492 seconds [18:40] Val (~val@val.linuxfr.org) joined #vserver. [18:40] hi [18:47] hi [18:48] Bertl_zZ (~herbert@MAIL.13thfloor.at) left irc: Quit: Bertl_zZ has no reason [18:48] Bertl (~herbert@212.16.62.51) joined #vserver. [18:49] hi ! [18:49] hey Bertl [18:51] you vanished so fast yesterday ... you must have had a good reason ;) [18:53] Bertl: a friend came by, for the third time asking me to help him [18:53] and after that the party room at my dorm was open :) :) [18:55] as I said .. a good reason ... [18:55] Bertl: yeah [19:05] IIRC, I asked you what patches you use to get your stuff running (the encryption) [19:07] Bertl: patch-int and loop-jari [19:07] well they should not be too hard to apply on 2.4.22 then ... [19:07] Bertl: no [19:41] noel (~noel@80.142.169.165) left irc: Ping timeout: 483 seconds [19:41] hrm [19:41] wonde what makes loads shoot to 260 and kswapd use 99% CPU [19:43] @matt probably something like a forkbomb ... [19:44] matta_ (root@66.103.140.19) joined #vserver. [19:44] yeah [19:45] number of processes jumped up to almost 1300 [19:45] O(1) would have helped here... [19:45] :) [19:45] are you sure? [19:45] i've done forkbomb tests on O(1) and non O(1) and it helps a LOT [19:45] Bertl: did you read http://bulk.fefe.de/scalability/ [19:45] without it kills the system [19:46] with it there is a slight lag then everything is normal, just with more processes [19:46] was this with my O(1) port? [19:46] no [19:46] stock O(1) [19:46] so we know exactly nothing then ;) [19:46] uh, well i'm saying under stock [19:46] it helps with a forkbomb [19:47] yes, but it doesn't help with the vserver ... (the stock version) ;) [19:47] i don't think it was a forkbomb though [19:47] i think it was normal load [19:47] i could get around a little bit, just very very slow [19:47] well, some program which creates threads, act like a forkbomb, when the threads start to die ... for whatever reason (badly written software) [19:49] but normal load is 900 processes [19:49] and this was 1280 [19:49] loads of 260+ [19:49] nothing abnormal except kswapd using 99% of CPU at bursts [19:49] and kswapd using 38hours of CPU time [19:49] the problem is that each process needs some time to die ... this can be much longer than the time required to fork ... [19:49] but memory wasn't stressed [19:50] per vserver process limits can help here ... [19:50] they are in affect [19:50] 128/256 per vserver [19:50] the biggest user only had 100 processes though [19:51] I had a report, that the process limits (or the accounting) doesn't work as expected ... [19:52] any comments to that? [19:53] matta (matta@tektonic.net) left irc: Read error: Connection reset by peer [19:54] serving (~serving@213.186.191.62) joined #vserver. [19:57] uhm [19:57] works fine as far as I can tell [19:57] i've had servers hit their limit [19:57] hrm [19:58] i tried to find a report/graph of linux scalability as the number of processes grows [19:58] all I found was something saying the stock scheduler is using 25% of the CPU for scheduling at 1000 processes [19:58] the report said, it hits the limit too soon, like startup requiring 100 processes minimum ... [19:58] never heard of that one [19:59] just asking ;) [20:02] sv (~sv@62.253.119.28) joined #vserver. [20:02] Anyone here? [20:02] noone [20:02] nope! [20:02] you guys, such kidders [20:02] we do what we can ... [20:03] I've just noticed that Herb's c17g is not split properly ... wanted to know how to co-ordinate fixing it with him [20:03] matta (matta@tektonic.net) joined #vserver. [20:03] matta_ (root@66.103.140.19) left irc: Quit: ircII2.8.2-EPIC3.004 --- Bloatware at its finest. [20:03] Has Herb been in da house recently? [20:03] hmm has he done a bad job again? [20:03] did you guys read http://bulk.fefe.de/scalability/ yet? [20:04] hahahaha [20:04] ROFL [20:04] matta: be kind [20:04] JonB: i'm trying to load it... [20:04] very slow [20:04] sv: i'm Herbert! [20:04] and I'm Sam, so nice to finally meet you irc to irc [20:05] matta: you are ? i thought Bertl was [20:05] nobody ever want's to talk to me ... [20:05] LOL [20:05] sv: Mr. Sam ViLLain ? [20:05] I'm no crook, it's Vilain. But aii [20:06] the inventor of ILI? [20:06] sv: hehe, i know, you must get that alot [20:06] eh, yeah [20:07] but I'll admit that I got the idea from a collegue [20:07] ncw, inventor of the preempt-stats `top' utility! [20:08] great stuff ... [20:08] oh well time to upgrade that to server to vserver-1.0+o1.. [20:08] oh wait.. [20:08] :/ [20:09] Bertl: i kind find the old userland tools at www.linux-vserver.org [20:09] So, Herb ... I'm going to try to port your c17g to the -ac series kernels now. I've already noticed one miscategorised patch ... how would you like to work this? [20:09] Bertl: there is only a link to the competing implemention [20:09] depends ... let's hear what the problem is ... [20:09] JonB: that scalability page doesn't load [20:10] No real problem, just eg kernel/timer.c patch is in the _base.diff, should be in the _sched.diff [20:10] matta: i know, it doesnt scale to handle a slashdotting [20:10] ahh okay, that is something I discovered last time, but didn't find it worth changing at the moment .. but you are right ... [20:11] ah, i'm only interested in scheduler scalability anyway [20:11] matta: it was just a comparison of linux 2.4 and 2.6 + *BSD [20:11] matta: how various stuff scaled [20:11] @sv and did you check the port of your stuff, is it correct? [20:12] @sv I wasn't sure because I had to throw out some of the RT stuff ... [20:12] I need to do it once more, more thoroughly, and keep it split [20:13] well, that would be perfect ... [20:13] matta: there is a discussion at slashdot where someone mentions a mirror [20:14] i got it loaded [20:14] There is the small matter of the segments of the patch that don't apply cleanly on the -ac4 series, mainly because the context is different [20:14] i must be colorblind [20:14] @sv well I never tried on the ac patches because of the scheduler ... [20:15] ! One of the best reasons *to* use it :-) [20:15] matta: i hope not, because he FSCK'ED up the colors by not using the same colors consistently throughout the test [20:15] @sv I'm not sure, but matt is on your side ;) [20:16] i 100% agree [20:16] I WANT IT [20:16] i'm fiending for it like a crackhead [20:16] since Alex's patch used RedHat kernel it had the O(1) scheduler [20:16] and i'll tell you it performed much better [20:16] I like the -ac series kernels. I mean, look who produces them - a guy working inside Red Hat, who get all of the bug reports from high end users of Red Hat [20:17] but he had no time to test it extensively yet ;) [20:17] Bertl: machine troubles [20:17] Bertl: neither does linus [20:17] A vanilla 2.4.22 kernel won't even boot my shiny dual Opteron box [20:17] ok, if I test it you make a quuck port to 2.4.22-c17e-rmap :) [20:18] sv: who would use a 2.4 kernel anyway, 2.6 is the way to go (see http://bulk.fefe.de/scalability/ [20:18] nope, but we can talk about a 2.4.22-c17g-rmap port ... [20:18] Bertl: then dl/ml ported to c17g-rmap also? it needs to be done for 1.0 anyway.. :) [20:18] JonB: people that want to use vserver (duh) [20:18] that is already done ... *G* [20:19] I thought that Alan used to include Riel's VM system in the -ac series [20:19] matta: i hope it gets ported to 2.6 soon [20:19] JonB: the O(1) scheduler will make 2.4 like 2.6 in the forkbomb test [20:19] Bertl: where?? [20:19] ok i'm doing a redhat install now... [20:19] it'll be tested today [20:19] get porting! [20:19] matta: please elaborate [20:19] well, the old patches apply nicely ... [20:19] oh [20:20] okay sam, what do you need from me (to help you)? [20:20] JonB: look at that page on the fork benchmark [20:21] matta: oh, yes of course [20:21] JonB: see how 2.6 is a flat line, meaning virtually unlimited process scalability [20:21] and how 2.4 is a steady ramp up [20:21] at around 200 process the system is most likely at loads of 200+ and takes a few minutes to issue an ls [20:21] mugwump (~sv@62.253.119.28) joined #vserver. [20:22] while 2.6 is still very speedy [20:22] er, 2000 processes [20:22] "flatline" reminds me of a very bad movie with some young doctors killing themselves and doing CPR to get people back [20:22] Up to how many CPUs though .. have they waxed 8 yet? [20:22] the difference there is 2.6 has an O(1) scheduler as this person notes [20:22] Action: mugwump eats sv [20:22] sv (~sv@62.253.119.28) left irc: Quit: Leaving [20:23] there are patches of the O(1) scheduler to 2.4, RedHat includes them by default [20:23] and what Bertl is doing is porting it to work with vserver [20:24] Just seems a waste of time, when there are other more stable kernel trees that include it [20:25] hmm, well I ripped it out from the -aa tree, so it should work ;) [20:26] I see someone's been merging rmap and vserver too [20:27] yep, guilty! [20:27] mugwump: i don't think we want vserver to "depend" on someone elses tree too much [20:27] matta: why not ? [20:27] matta: i would prefer to depend on linus tree [20:27] You mean Marcelo's tree [20:27] Action: Bertl smiles ... [20:28] mugwump: technicaly yes, but since linus gave that to marcelo, i still consider it linus tree [20:28] What magical status does that give the code ? [20:28] mugwump: thats the most official you can get, and that gives everyone a common ground [20:29] the main tree is constantly playing catchup with -ac and -aa bugfixes that come from the people that are really putting the money into developing the code base [20:29] hmm, I would say, vserver is stable on the mainline tree (which is well tested, mostly ;), and that is the reason for keeping it on that base ... [20:30] Sure, granted [20:30] mugwump: yes, but that also means that stuff gets tested in -ac and -aa before it goes into the mainline kernel [20:30] I have no problem with a -ac or -aa or -xy branch ... [20:30] -ac would be nice [20:30] Probably more linux boxes run on an -ac based kernel than a pure Linus one, given the installed base of Red Hat [20:30] -ac is essentially the RedHat kernel, correct? [20:30] maybe not, hard to measure of course [20:31] but I don't want to give up the stable/proven mainline for some features, even if they are important ones ;) [20:31] right... [20:31] all I can say is that I ran the RedHat 2.4.18 kernel on a fairly loaded server then switched to base 2.4.22.... [20:32] and performance was much better before [20:32] perhaps you can explain something to me... [20:32] under RedHat 2.4.18 I would normally have 20 processes "Running" at a time [20:32] The RedHat 2.4.18 kernel has about 600 patches applied to it [20:33] It's probably closer to 2.4.24 than 2.4.22 :-) [20:33] after switching to 2.4.22 under the same type of load only 2-6 are running at a time [20:33] mugwump: i've read through the patch list in their spec file, someusel stuff in there [20:33] matta: just get a bigger machine, like the one sv has [20:33] i have a big machine (i think) [20:33] that's hte other thing [20:33] hey I like the color blue, what about you? [20:33] O(1) scheduler improves SMP scalability [20:34] Action: mugwump adjusts the temperature control on his motherboard's CPU fan <-> temperature control chip [20:34] matta: i was joking [20:34] and I have a SMP server :) [20:34] anyhow... gone for a little bit [20:36] What's changed betweem c17f & g? [20:37] the syscall switch .. [20:37] there is a g2 too, which fixes a bug ... [20:37] I see, nothing major then ;-) [20:37] well, not for scheduler and the rest ;) [20:38] Is the userland support complete? [20:38] enricos tools support the new syscall interface ... so yes [20:48] http://vilain.net/linux/ctx/split-2.4.22-ac4-c17g/01_2.4.22-ac4_base.diff # One ... AA HAH HAH HAH... [20:49] mugwump: whats so funny ? [20:49] It's the count [20:50] is __NR_swapcontext one of ours? [20:52] guess not then [20:52] who cares, it's just ppc arch anyway ;-) [20:52] nope in 17f we have 2 syscalls ... [20:52] mugwump: well, i for one would like to have a power5 [20:52] new_s_context and set_ipv4root ... [20:53] from c17g on we'll have just sys_virtual_context ... [20:55] What a high syscall number we have [20:56] mugwump: yeah, we want syscall 0 [20:57] hey why not, it's not even used [20:57] One day, when the rest of the world sees what an important project vserver is [20:57] @sam add this one http://vserver.13thfloor.at/Experimental/delta-c17g-c17g2.diff [21:00] cheers [21:00] as a part of what? Base ? [21:00] nope it's the syscall part only ... [21:01] so switch in this case ... [21:02] Cool, that's the part I'm on :-) [21:04] http://vilain.net/linux/ctx/split-2.4.22-ac4-c17g/02_2.4.22-ac4_switch.diff # Two ... AH AA AA AAAA... [21:05] Oh no, now it's sched ;) [21:06] patch-2.4.23-pre7-O1c17f.diff.bz2 [21:06] this is what I should test right? [21:06] not 2.4.22-c17g2O1 ? [21:06] hmm is there a 2.4.22-c17g2O1? [21:06] no :) [21:07] would you like to test 2.4.22-c17g2O1? [21:07] optimally [21:07] give me a minute ... [21:08] so this is what happened: [21:08] 04:00:01 AM 0 970 0.10 0.29 [21:08] 04:05:26 AM 1 1027 95.82 40.57 [21:08] 04:11:31 AM 0 1051 110.17 86.76 [21:08] 04:11:31 AM runq-sz plist-sz ldavg-1 ldavg-5 [21:08] 04:15:53 AM 2 1058 115.05 100.94 [21:08] 04:20:41 AM 0 1087 125.18 119.51 [21:08] 04:28:10 AM 0 1202 195.88 166.97 [21:08]