Skip to contentSkip to conversation

Win32 equivalent to GetTickCount systemcall (i386)

PATCH In review David Engraf 7 participants 14 messages Dec 6, 2005

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 Win32 equivalent to GetTickCount systemcall (i386)

This patch adds a new systemcall on i386 architectures returning the jiffies value to the application.
As a kernel developer you can use jiffies but from the user space there is no equivalent function which counts every millisecond like the Win32 GetTickCount.

linux-2.6.15-rc5-mm1

asm-i386/unistd.h renamed from asm-i386/unistd_orig.h +2 -1
diff -puN include/asm-i386/unistd_orig.h include/asm-i386/unistd.h
@@ -300,8 +300,9 @@
 #define __NR_inotify_add_watch	292
 #define __NR_inotify_rm_watch	293
 #define __NR_migrate_pages	294
+#define __NR_tickcount	295
 
-#define NR_syscalls 295
+#define NR_syscalls 296
 
 /*
  * user-visible error numbers are in the range -1 - -128: see

diff -puN arch/i386/kernel/syscall_table_orig.S
arch/i386/kernel/syscall_table.S
--- arch/i386/kernel/syscall_table_orig.S 2005-12-06
12:07:14.000000000 +0100
+++ arch/i386/kernel/syscall_table.S 2005-12-06 12:10:40.000000000 +0100
@@ -294,3 +294,4 @@ ENTRY(sys_call_table)
.long sys_inotify_add_watch
.long sys_inotify_rm_watch
.long sys_migrate_pages
+ .long sys_tickcount

sys.c renamed from sys_orig.c +6 -0
diff -puN kernel/sys_orig.c kernel/sys.c
@@ -1855,3 +1855,9 @@ asmlinkage long sys_prctl(int option, un
 	}
 	return error;
 }
+
+asmlinkage long sys_tickcount(long __user *ret)
+{
+	if (copy_to_user(ret, (void*)&jiffies, sizeof(long)))
+	return 0;
+}

Thanks
David Engraf

____________
Virus checked by G DATA AntiVirusKit
Version: AVK 16.2037 from 06.12.2005
Virus news: www.antiviruslab.com

#1 lore raw
Quoted 5 lines · David Engraf

This patch adds a new systemcall on i386 architectures returning the jiffies value to the application.
As a kernel developer you can use jiffies but from the user space there is no equivalent function which counts every millisecond like the Win32 GetTickCount.

a few comments

1) jiffies are 64 bit not 32
2) jiffies are not a constant time, eg HZ is a config option, exposing that internal counter to userspace sounds wrong, after all what would it be used for
3) wouldn't it be better to expose a wallclock time thing which has a constant unit of time between all kernels?

(and.. wait.. isn't that called gettimeofday() )

#2 lore raw
Quoted 2 lines · David Engraf
Quoted 1 line

This patch adds a new systemcall on i386 architectures returning the

jiffies

Quoted 2 lines
Quoted 2 lines

value to the application.
As a kernel developer you can use jiffies but from the user space there

is

Quoted 6 lines
Quoted 2 lines

no equivalent function which counts every millisecond like the Win32 GetTickCount.

a few comments

1) jiffies are 64 bit not 32

Jiffies is defined as "unsigned long volatile __jiffy_data jiffies". On i386 machines unsigned long is 32.

Quoted 3 lines

2) jiffies are not a constant time, eg HZ is a config option, exposing that internal counter to userspace sounds wrong, after all what would it be used for

Right, HZ is defined as USER_HZ which can be set over the config. On normal desktop systems it should be 1000 on other machines it could also be 100 or
250. Either we can ignore the setting and the function depends on the USER_HZ config, or we have to calculate the right value with USER_HZ.

Quoted 2 lines

3) wouldn't it be better to expose a wallclock time thing which has a constant unit of time between all kernels?

What is it?

Quoted 1 line

(and.. wait.. isn't that called gettimeofday() )

Not really gettimeofday is based on the date and time, but what if the user changes the date, the counter would also change.

____________
Virus checked by G DATA AntiVirusKit
Version: AVK 16.2038 from 06.12.2005
Virus news: www.antiviruslab.com

#3 lore raw
Quoted 4 lines · David Engraf
Quoted 1 line

(and.. wait.. isn't that called gettimeofday() )

Not really gettimeofday is based on the date and time, but what if the user changes the date, the counter would also change.

see 'man clock_gettime', and CLOCK_MONOTONIC:

CLOCK_MONOTONIC
Clock that cannot be set and represents monotonic time since some unspecified starting point.

and it has microsecond resolution.

Ingo

#4 lore raw
Quoted 9 lines · David Engraf
Quoted 5 lines
Quoted 2 lines

(and.. wait.. isn't that called gettimeofday() )

Not really gettimeofday is based on the date and time, but what if the user changes the date, the counter would also change.

see 'man clock_gettime', and CLOCK_MONOTONIC:

Quoted 8 lines

CLOCK_MONOTONIC
Clock that cannot be set and represents monotonic time
since
some unspecified starting point.

and it has microsecond resolution.

Ingo

You're right, clock_gettime with CLOCK_MONOTONIC seems to be date/time independent. For a GetTickCount implementation it is absolutely enough.

Thanks
David Engraf

____________
Virus checked by G DATA AntiVirusKit
Version: AVK 16.2039 from 06.12.2005
Virus news: www.antiviruslab.com

#5 lore raw
In reply to David Engraf
Quoted 9 lines · David Engraf
Quoted 2 lines · David Engraf
Quoted 1 line

This patch adds a new systemcall on i386 architectures returning the

jiffies

Quoted 2 lines
Quoted 2 lines

value to the application.
As a kernel developer you can use jiffies but from the user space there

is

Quoted 2 lines
Quoted 2 lines

no equivalent function which counts every millisecond like the Win32 GetTickCount.

Quoted 6 lines
Quoted 3 lines

a few comments

1) jiffies are 64 bit not 32

Jiffies is defined as "unsigned long volatile __jiffy_data jiffies". On i386 machines unsigned long is 32.

but it's a subvariable of jiffies64 which is 64 bit

Quoted 10 lines
Quoted 5 lines

2) jiffies are not a constant time, eg HZ is a config option, exposing that internal counter to userspace sounds wrong, after all what would it be used for

Right, HZ is defined as USER_HZ which can be set over the config. On normal desktop systems it should be 1000 on other machines it could also be 100 or
250. Either we can ignore the setting and the function depends on the USER_HZ config, or we have to calculate the right value with USER_HZ.

but then.. why?

#6 lore raw
In reply to David Engraf
Quoted 3 lines · David Engraf
Quoted 1 line

(and.. wait.. isn't that called gettimeofday() )

Not really gettimeofday is based on the date and time, but what if the user changes the date, the counter would also change.

If you want a monotonic clock, just use clock_gettime (CLOCK_MONOTONIC, &ts);

Jakub

#7 lore raw
In reply to David Engraf
Quoted 1 line · David Engraf
Quoted 1 line · David Engraf

[.../9

Quoted 9 lines
Quoted 2 lines

3) wouldn't it be better to expose a wallclock time thing which has a constant unit of time between all kernels?

What is it?

Quoted 1 line

(and.. wait.. isn't that called gettimeofday() )

Not really gettimeofday is based on the date and time, but what if the user changes the date, the counter would also change.

man 2 times
And use the returned value.

Bernd

Signature · 3 lines
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services
#8 lore raw
Quoted 14 lines · David Engraf
Quoted 1 line
Quoted 1 line · David Engraf

[.../9

Quoted 8 lines
Quoted 2 lines

3) wouldn't it be better to expose a wallclock time thing which has a constant unit of time between all kernels?

What is it?

Quoted 1 line

(and.. wait.. isn't that called gettimeofday() )

Not really gettimeofday is based on the date and time, but what if the

user

Quoted 1 line

changes the date, the counter would also change.

Quoted 8 lines

man 2 times
And use the returned value.

Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services

times has only 10ms resolution, we need at least 1ms.

David

____________
Virus checked by G DATA AntiVirusKit
Version: AVK 16.2039 from 06.12.2005
Virus news: www.antiviruslab.com

#9 lore raw
Quoted 2 lines · David Engraf

times has only 10ms resolution, we need at least 1ms.

It actually has jiffies resultion. Your measurements must have been quite off.

-Andi

#10 lore raw
Quoted 7 lines · Andi Kleen
Quoted 1 line · David Engraf

times has only 10ms resolution, we need at least 1ms.

It actually has jiffies resultion. Your measurements must have been quite off.

I beg to differ: times has a 10 ms resolution ( ie 1/USER_HZ)

times() is supposed to return clock_t expressed in USER_HZ, wich is still 100, regardless of the kernel HZ

I just checked sources and sys_times() do use jiffies_64_to_clock_t()

Eric

#11 lore raw
Quoted 10 lines · Eric Dumazet

Andi Kleen a ?crit :

Quoted 7 lines
Quoted 1 line · David Engraf

times has only 10ms resolution, we need at least 1ms.

It actually has jiffies resultion. Your measurements must have been quite off.

I beg to differ: times has a 10 ms resolution ( ie 1/USER_HZ)

You're right. Sorry for the confusion. clock_gettime is the way to go.

-Andi

#12 lore raw
In reply to David Engraf
Quoted 5 lines · David Engraf

This patch adds a new systemcall on i386 architectures returning the jiffies value to the application.
As a kernel developer you can use jiffies but from the user space there is no equivalent function which counts every millisecond like the Win32 GetTickCount.

You want a timer that never go backwards, right?

Use clock_gettime(CLOCK_MONOTONIC). It's the POSIX way to do this.

-Andi

#13 lore raw
Quoted 8 lines
Quoted 1 line · David Engraf

This patch adds a new systemcall on i386 architectures returning the

jiffies

Quoted 2 lines

value to the application.
As a kernel developer you can use jiffies but from the user space there

is

Quoted 8 lines
Quoted 2 lines

no equivalent function which counts every millisecond like the Win32 GetTickCount.

You want a timer that never go backwards, right?

Use clock_gettime(CLOCK_MONOTONIC). It's the POSIX way to do this.

-Andi

Yes, clock_gettime works(CLOCK_MONOTONIC), thanks.

David

____________
Virus checked by G DATA AntiVirusKit
Version: AVK 16.2042 from 06.12.2005
Virus news: www.antiviruslab.com