Hi Dave, this patch replaces PSCHED_CLOCK_SOURCE by three new config options and fixes HTB compilation with CONFIG_NET_SCH_CLK_GETTIMEOFDAY. Patch compiles with all three options. If you like it I wi
I have a patch (to the original) which replaces the arch dependant CPU stuff with the arch neutral sched_clock() which although slightly slower works on a x86_64 and ia64 as well.
I also want to add sparc64 %tick register support here too. This is an area with a lot of potential cleanup. We should made an asm/pkt_sched.h to abstract out the clock source implementation instead
Here is the patch I have been testing against 2.6.8-rc1 to use sched_clock. diff -Nru a/include/net/pkt_sched.h b/include/net/pkt_sched.h -- a/include/net/pkt_sched.h 2004-07-12 11:06:52 -07:00 +++ b
David S. Miller wrote: I also want to add sparc64 %tick register support here too. This is an area with a lot of potential cleanup. We should made an asm/pkt_sched.h to abstract out the clock source
Patrick McHardy wrote: David S. Miller wrote: I also want to add sparc64 %tick register support here too. This is an area with a lot of potential cleanup. We should made an asm/pkt_sched.h to abstrac
This looks great. As you mention some platforms return zero, for example sparc32, for get_cycles(). I suggest we just expand the dependency list for NET_SCH_CLK_TSC to include SPARC64 PPC64 and perha
David S. Miller wrote: This looks great. As you mention some platforms return zero, for example sparc32, for get_cycles(). I suggest we just expand the dependency list for NET_SCH_CLK_TSC to include
I see. I know for a fact that sparc64 meets this criterion, and I'm pretty sure ppc64 does too. We could bug check this in psched calibration, in fact I think we should.
David S. Miller wrote: It needs to increment at slightly above 1Mhz, otherwise delay will be zero after this division and everything will fall apart: delay /= rdelay. I see. I know for a fact that sp
Patrick McHardy wrote: David S. Miller wrote: We could bug check this in psched calibration, in fact I think we should. Done by this patch. I used BUG_ON instead of just printing a warning because us
Patrick McHardy wrote: I'm pretty sure x86, x86_64, alpha, sparc64, ppc64 and ia64 can be used. I'm not sure if the frequency of all ppcs is high enough, so I won't add support for them. This is the
We can't use this stuff on Alpha, it's cycle counter overflows after just 10 minutes. It works very strangely, something like only the lower 32-bits are guarenteed to be continually incrementing. I'm
David S. Miller wrote: We can't use this stuff on Alpha, it's cycle counter overflows after just 10 minutes. It works very strangely, something like only the lower 32-bits are guarenteed to be contin
David S. Miller wrote: On Fri, 23 Jul 2004 19:14:48 +0200 Patrick McHardy <kaber@xxxxxxxxx> wrote: Dave, do you want me to provide patches for 2.4 as well ? Sure, give it a shot. If it gets too ugly
David S. Miller wrote: Let me know if you get feedback or not. For now I'm pushing to Linus with Alpha removed from the list. According to Richard Henderson it should work fine. The fastest Alpha cyc