linux-kernel - Re: [PATCH] Add an offset in the cyc2ns computation to fix sched

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Sun, 18 Mar 2007 23:09:11 +0100
From:	"Guillaume Chazarain" <guichaz@...il.com>
To:	"Mathieu Desnoyers" <mathieu.desnoyers@...ymtl.ca>
Cc:	"Andi Kleen" <ak@...e.de>, "john stultz" <johnstul@...ibm.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Add an offset in the cyc2ns computation to fix sched_clock jumps

2007/3/18, Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>:
> Hi Guillaume,

Hi Mathieu, thanks for your extensive reply.

> yet another level of band-aid over a

I don't agree it's a band-aid, changing the scaling coefficient
without adjusting an offset is a bug.

> broken architecture : AMD 7th and 8th generations

Actually in my case it's Intel Pentium M Dothan.

> other parts of the kernel suffers from those TSC inconsistencies

These other parts should not use sched_clock() but the clocksource
mechanism which in my case rightly avoids the TSC and uses the
ACPI timer. And I hope it will stay that way as the TSC definitely is
not a reliable time source in my case for the reasons you gave.

> it does not deal with frequency scaling due to temperature related
> events, and does not, as I recall, deal with frequency scaling in halt
> mode.

Yep, I saw this, that's why I said in this case sched_clock() does not
return nanoseconds as it thinks it does. Thankfully, the scheduler is
not stressed when the CPU is idle. Anyway, spilling on another thread,
this is a bonus point for the RSDL scheduler as it does not account
the sleeping time of tasks.

> I also plan to update this global last_tsc every timer tick to give a
> higher bound to time accuracy.

Then I don't see how this is significantly better than the ACPI timer
except for the increased precision in short durations. For example,
my CPU can lower its frequency down to 798 MHz and the TSC
down to 350 MHz or so (measured). So your clock will think the
TSC runs at 798 MHz  when it runs at 350MHz, and every tick the
clock will make a half tick jump to catch up with its delay.

The best solution seems to buy a new computer with a reliable
TSC ;-)

Thanks.

-- 
Guillaume
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/