Thanks, everyone, for all of your comments on my TSC patch. As Alan pointed
out, this is indeed my first ever kernel patch and I freely admit to being a
bit out of my league. I will, however, try to answer the points raised over
the last day or so.
Concerns about efficiency of the patch: Totally valid. I fully accept this.
I would really like someone in the know to let me know whether this is actually
a measurable efficiency loss in the case of TSC-enabled kernels. I believe it
has NO loss of efficiency for any other kernel. I also would like input on how
the patch could be done better.
The comment that the #define statement was removed is absolutely accurate. It
was removed. I could not see a way to leave it in there *and* dynamically
determine if TSC had to be disabled (and then actually do the disable). With
the patch, do_gettimeoffset() is now a function pointer instead of a define.
This was already the case for non-TSC kernels but not for TSC kernels.
Regarding using the calculated processor speed instead of calculated
BogoMips... what's the difference? Why should one be preferred over the other?
I used loops_per_sec based on Alan's suggestion. I have no preference either
way.
Silent success path (i.e. removal of '...enabling TSC...') is quite reasonable.
My patch was intended to be preliminary and so I put extra information in
there. I believe we should leave in the error message if TSC is disabled but I
have no objections to removing the other message.
Complaint that my implementation is wrong (but my theory is right)... I'm sure
you are correct. Ideally, I'd like someone else to patch up my patch :) and
then everyone would be happy. Alternatively, please tell me how to fix what I
have done wrong.
One more (IMPORTANT) thing: Someone emailed me off the list saying that his
SMP machine has similar ping problems to mine. BUT HE IS USING THE SAME SPEED
CPUs. He has not yet tested my patch and I'm pretty sure it won't work for him
anyway, though a one-line change may make it work. Assuming that he is
experiencing the same problems as I am and assuming that his CPUs really are
the same speed, does anyone know why this may happen? I cannot think of a way
to make my patch dynamically determine this sort of problem?
--
Christopher Thompson http://hypocrite.org/
hypocrite.org will be down for several hours
on Saturday. Email to me may be delayed
during that time.
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/dmentre/smp-howto/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
