On Sat, 2003-01-25 at 15:50, kuznet@ms2.inr.ac.ru wrote:
> > In pkt_sched.h, it appears PSCHED_CLOCK_SOURCE is always PSCHED_JIFFIES,
> > so the CONFIG_X86_TSC'ed code under PSCHED_CPU is never even used. Would
> > anyone object to dropping the PSCHED_CPU chunk?
>
> This is the only working clock source for traffic control,
> which is described in comments by the way. jiffies are useful only
> for those who are interested only in plain bandwdth limiting.
Ok, so if I'm understanding correctly, it is in-fact used, but just
requires manually setting PSCHED_CLOCK_SOURCE for those special cases.
> And it was specially written _not_ to refer to arch/* at all
> (and not to be visible in large config), so I even do not understand
> how you managed to find this chunk of code, :-)
cscope! ;)
>
> > The profile.h code is a bit more tricky because we toss around timeval
> > but in some cases use them for the 64bit rdtscl values
>
> Sorry? I do not understand about what kind of troubles you are speaking,
> it uses elementary rdtsc, which returns two 32bit values. There are no
> references to something 64bit in this code.
Sorry, I was working out of memory rather then looking at the code. Let
me try to better explain my goals. I'm trying to remove the compile time
CONFIG_X86_TSC option, replacing it with runtime switches on
cpu_has_tsc. Thus I'm trying to unify the current TSC and non-TSC
functions.
So you are right, rdtsc does return two 32bit values, both of which are
stored in a timeval struct. However, timevals normally store {sec,
usec}, and in the rdtsc case we're storying {tsc_high,tsc_low}, which is
really just the two halves of a 64bit value. Since the tsc_low overflows
smoothly into tsc_high (on 32bit boundary) and usec overflows into sec
after only 1M, this causes the need for separate
net_profile_add/sub/accumulate implementations. My goal is to unify
these separate implementations, but as it is somewhat complicated (to
explain, at least) I wanted to give a heads up and get feedback from
those who know this code best.
Now, since it looks like you don't want any references to arch specific
code, switching on cpu_has_tsc may not be the way to go. Maybe we need
some alternate abstraction which would return the proper value on the
right arch? That way there wouldn't be the need for the duplicated
implementations.
Your thoughts?
thanks,
-john
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
