On Sunday 25 March 2007, Con Kolivas wrote: >On Sunday 25 March 2007 22:32, Gene Heskett wrote: >> On Sunday 25 March 2007, Con Kolivas wrote: >> >On Sunday 25 March 2007 21:46, Con Kolivas wrote: >> >> On Sunday 25 March 2007 21:34, malc wrote: >> >> > On Sun, 25 Mar 2007, Ingo Molnar wrote: >> >> > > * Con Kolivas <[EMAIL PROTECTED]> wrote: >> >> > >> For an rsdl 0.33 patched kernel. Comments? Overhead worth it? >> >> > > >> >> > > we want to do this - and we should do this to the vanilla >> >> > > scheduler first and check the results. I've back-merged the >> >> > > patch to before RSDL and have tested it - find the patch below. >> >> > > Vale, could you try this patch against a 2.6.21-rc4-ish kernel >> >> > > and re-test your testcase? >> >> > >> >> > [..snip..] >> >> > >> >> > Compilation failed with: >> >> > kernel/built-in.o(.sched.text+0x564): more undefined references >> >> > to `__udivdi3' follow >> >> > >> >> > $ gcc --version | head -1 >> >> > gcc (GCC) 3.4.6 >> >> > >> >> > $ cat /proc/cpuinfo | grep cpu >> >> > cpu : 7447A, altivec supported >> >> > >> >> > Can't say i really understand why 64bit arithmetics suddenly >> >> > became an issue here. >> >> >> >> Probably due to use of: >> >> >> >> #define NS_TO_JIFFIES(TIME) ((TIME) / (1000000000 / HZ)) >> >> #define JIFFIES_TO_NS(TIME) ((TIME) * (1000000000 / HZ)) >> >> >> >> Excuse our 64bit world while we strive to correct our 32bit >> >> blindness and fix this bug. >> > >> >Please try this (akpm please don't include till we confirm it builds >> > on ppc, sorry). For 2.6.21-rc4 >> > >> >--- >> >Currently we only do cpu accounting to userspace based on what is >> >actually happening precisely on each tick. The accuracy of that >> >accounting gets progressively worse the lower HZ is. As we already >> > keep accounting of nanosecond resolution we can accurately track >> > user cpu, nice cpu and idle cpu if we move the accounting to >> > update_cpu_clock with a nanosecond cpu_usage_stat entry. This >> > increases overhead slightly but avoids the problem of tick aliasing >> > errors making accounting unreliable. >> >> I'm playing again because the final 2.6.20.4 does NOT break amanda, >> where 2.6.20.4-rc1 did. > >Yes only the original version I posted on this email thread was for an > RSDL 0.33 patched kernel. That original patch should build fine on i386 > and x86_64 (where I tried it). This version I sent out following Ingo's > lead has 2.6.21-rc4 in mind (without rsdl).
And since I have an amdump session running in the background using the first 2.6.20.4-rdsl-0.33 patch I got from your web page about an hour ago, I am very pleased with this, I still have a machine as gzip is being restrained to a max of about 83% of the cpu. And according to my grepping of the /tmp/amanda-dbg/client/Daily/sendsize* files, this patch does not break amanda. Also, to Ingo Molnar, I've removed that sched-batch thing from my scripts as this feels considerably smoother in comparison. Thank you very much, Con, and I hope you are improving. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Aberdeen was so small that when the family with the car went on vacation, the gas station and drive-in theatre had to close. - 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/
