fa.linux.kernel Google Group

Re: [RFC patch 0/4] TSC calibration improvements

2008-09-06T21:27:31Z

I know, but I'm not going to do that at 11PM.

I didn't know that sending a test patch which is admittetly not pretty
is a capital crime nowadays.
In future I'll restrict myself to look at such stuff only on Monday to
Friday between 9AM and 5PM and send test/RFC patches only when they
got approved by the nonshitapproval committee, which holds a meeting

Re: [RFC patch 0/4] TSC calibration improvements

2008-09-06T21:27:29Z

Show me. Because I simply don't believe you.
The first code is simply _wrong_ - except if "expect" isn't even _used_
afterwards (in which case gcc can optimize away the last unused write).
And I strongly suspect that that is what you've seen.
Because quite frankly, if what you describe is real, then your gcc is

Re: hotplug create_slot hang

2008-09-06T21:27:27Z

On Sat, Sep 6, 2008 at 12:44 PM, Andrew Morton
current tip/master
two days ago works.
YH

Re: [RFC patch 0/4] TSC calibration improvements

2008-09-06T21:15:59Z

One gcc does:
i++;
if (i >= QUICK_PIT_ITERATIONS)
goto out;
expect--;
The other one does:
i++;
expect--;
if (i >= QUICK_PIT_ITERATIONS)
goto out;
Don't ask me which one is correct. It's just reality :(
/me goes back to consume legal german drugs
tglx

Re: [RFC patch 0/4] TSC calibration improvements

2008-09-06T21:15:36Z

No. I'm telling you, because that patch IS CRAP.
You can move that thing _out_ into a function of its own.
Look at this piece fo CRAP, and tell me, HOW MANY TIMES do you want to
repeat it?
+ /*
+ * Return the fast_calibrate value when neither hpet
+ * nor pmtimer are available.

Re: [RFC patch 0/4] TSC calibration improvements

2008-09-06T21:11:16Z

Quite the reverse. We have a guarantee that it _is_ decremented.
Adn that guarantee is very much about the C language.
for (a ; b ; c) {
..
}
translates as
a;
while (b) {
..
continue:
c;
}
And this has absolutely _nothing_ to do with any gcc oddity or anything
else.
The fact is, the code that Ingo added was totally bogus. The real bug was

Re: [RFC patch 0/4] TSC calibration improvements

2008-09-06T20:59:53Z

Guys, please.
Show some _taste_.
Dammit, stop adding random crap to "native_calibrate_tsc()" and make it
look like total and utter SHIT.
If you want to do that
tsc1 = tsc_read_refs(&ref1, hpet);
..
tsc2 = tsc_read_refs(&ref1, hpet);
around calibration and comparing it, then do it *once*. Do it over the

Re: [RFC patch 0/4] TSC calibration improvements

2008-09-06T20:58:34Z

Just straight forward german beer :)

diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 6dab90f..3bfe083 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -310,8 +310,8 @@ static unsigned long quick_pit_calibrate(void)
unsigned char expect = 0xfe;

t1 = get_cycles();

Re: [uml-devel] [PATCH 2/6] UML: Don't valgrind userspace

2008-09-06T20:56:20Z

UML is part of the kernel, so getting a memory reference checker (valgrind)
running in UML is part of the kernel, too. The concept of "escape from the
virtualizer" eventually occurs to more than just memory reference checkers.
It wasn't taken a few months ago when the valgrind patches for UML were
first proposed. The list of free bits in that flag word is now empty.

Re: [RFC patch 0/4] TSC calibration improvements

2008-09-06T20:55:43Z

Oh, you mean te "--expect" in the last pit_expect_msb(). Yeah, that one
looks bogus, but I don't understand what it has to do with gcc at all.
"expect" is an unsigned char. There are absolutely _zero_ issues with
overflow, underflow, random phases of the moon, madness levels or anything
else. But yes, it does look like Ingo screwed up when adding that final

Re: [RFC patch 0/4] TSC calibration improvements

2008-09-06T20:52:56Z

If Alok has the second check in place and is actually worried about
that 288us impact, then we can add the following (untested), which
does not impact the speed of the check.
Against -tip x86/tsc
Thanks,
tglx
---
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 6dab90f..3bfe083 100644

Power management stuff

2008-09-06T20:51:58Z

Hello,
I have a few ideas/questions about some power management-related issues:
1) How could we get the current frequency/voltage settings for the CPU,
fr example when using SpeedStep by using the /proc filesystem?
2) It would be nice to modify a bit the CPU throttling API to be able to
set a max value when using dynamic governors, like ondemand.

Re: [RFC patch 0/4] TSC calibration improvements

2008-09-06T20:51:30Z

Umm. What? You're on some odd drugs.
Linus

Re: [RFC patch 0/4] TSC calibration improvements

2008-09-06T20:38:38Z

My bad. Did not test that against -tip, just applied it from mail :)
Just checked. The -tip version still has the expect-- in the for()
which might lead to stupid results depending on the gcc madness level.
Thanks,
tglx

Re: [RFC patch 0/4] TSC calibration improvements

2008-09-06T20:30:26Z

My original patch actually had that, and Ingo added it to the -tip tree
too (I think), so that should be the one we're discussing anyway. I just
didn't think it would ever trigger in practice, which is why I removed it.
Mea culpa.
Linus