public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: george anzinger <george@mvista.com>
To: "Randy.Dunlap" <rddunlap@osdl.org>
Cc: Linus Torvalds <torvalds@transmeta.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/3] High-res-timers part 1 (core) take 23
Date: Tue, 07 Jan 2003 16:05:06 -0800	[thread overview]
Message-ID: <3E1B6B32.5D369127@mvista.com> (raw)
In-Reply-To: Pine.LNX.4.33L2.0301071111210.2498-100000@dragon.pdx.osdl.net

"Randy.Dunlap" wrote:
> 
> Hi George,
> 
> On Fri, 3 Jan 2003, george anzinger wrote:
> 
> | Just in case you might like high res timers...
> |
> | Now for 2.5.54-bk1
> 
> Using exactly 2.5.54-bk1 + the POSIX clocks/timers + HRT patches,
> when I run the HRT support test suite (do_test), I'm getting
> intermittent (but often) spinlock BUGs.  I've done this both without
> and with HIGH_RES_TIMERS enabled (i.e., different kernels built
> in the same source tree).
> Details are below.
> 
> Yes, I expect to be able to run the test suite on a kernel that
> doesn't have HIGH_RES_TIMERS enabled...and to see the tests fail.

Actually the tests should detect low res and adapt
reasonably well.  The one problem(?)is that the
clock_nanosleep test finds the kernel timing bug introduced
by not pushing the wall clock 1/HZ on a tick. (The current
2.5 kernel actually pushes time a bit more than this
introducing a difference in the rate of time passing between
the wall clock an the jiffies.  This causes timers to expire
early which is a big NO-NO, standard wise.)

This is most easily seen by doing:

time sleep 60 

and noticing that it completes in less than 60 seconds, even
with the scheduling overhead.

> 
> | -------
> | This patch supplies the core changes to implement high
> | resolution timers.  Mostly it changes the timer list from
> | the multi stage hash (or cascade) list to a single stage
> | hash list.  This change makes it easy to configure the list
> | size for those who are concerned with performance.  It also
> | eliminates the "time out" for the cascade operation every
> | 512 jiffies, thus eliminating possibly long preemption
> | times.  On input from Stephen Hemminger<shemminger@osdl.org>
> | the configuration of the timer list size is no longer
> | presented as a configure option.  The code can still be
> | change (one line) to use larger or smaller lists.
> |
> | With this patch applied, the system should boot and run much
> | as it does prior to the patch.  This patch depends on the
> | POSIX clocks & timers patch in that it assumes the changes
> | that patch made to timer.c to remove timer_t.  This
> | dependency can be removed if needed.
> 
> Couple of questions, please:
> 
> 1.  With HIGH_RES_TIMERS enabled, are all timers high-res timers,
> or does the API allow for some non-high-res timers (regular/normal)
> and some high-res-timers?

Actually you are asking a couple of questions here.  First,
the API (POSIX clocks & timers) is extended in the high res
patch to add two new clocks:
CLOCK_REALTIME_HR
CLOCK_MONOTONIC_HR

Only calls using these clocks will generate the high-res
overhead (usually an interrupt is required that is somewhere
between two 1/HZ interrupts).

On the other hand, the timers list handling code was
expanded to handle sub jiffie values (but only the above API
can set these values) so there is a small (very small)
addition in timer handling to at least test that the sub
jiffie is zero.

Normal timers, i.e. setitimer, select, time_schedule, etc.
all use the normal low res timers so nothing changes here.
> 
> 2.  With HIGH_RES_TIMERS enabled and no apps trying to use high-res
> timers, should I be able to detect any additional system overhead
> due to the HIGH_RES_TIMERS code?

You would need a very sensitive tool to detect any
additional overhead.  Still, as I mentioned above, there is
some.
> 
> Thanks,

And thank you for the bug report.

-g
> --
> ~Randy
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 2.5.54-bk1 + POSIX/HRT patches, with HIGH_RES_TIMERS=n:
> 
> kernel BUG at include/asm/spinlock.h:123!
> invalid operand: 0000
> CPU:    1
> EIP:    0060:[<c0130260>]    Not tainted
> EFLAGS: 00010086
> EIP is at good_timespec+0x80/0x180
> eax: 0000000e   ebx: ee5c471c   ecx: f63d7100   edx: c03e2dec
> esi: 00000000   edi: ed50df9c   ebp: ed50df8c   esp: ed50df78
> ds: 007b   es: 007b   ss: 0068
> Process timer_test (pid: 1970, threadinfo=ed50c000 task=f5b85800)
> Stack: c0369bc0 c0130244 ed50c000 ed50df9c 00000000 ed50dfbc c01308d6 00000000
>        ed50df9c 00000082 c0150e73 f7193ce4 40016000 00000032 ed50c000 4001526c
>        00000000 bfff9778 c0109537 00000000 00000000 bfff90a8 4001526c 00000000
> Call Trace:
>  [<c0130244>] good_timespec+0x64/0x180
>  [<c01308d6>] sys_timer_settime+0x16/0x180
>  [<c0150e73>] sys_read+0x33/0x40
>  [<c0109537>] system_call+0x7/0xb
> 
> Code: 0f 0b 7b 00 64 98 36 c0 59 58 8d b6 00 00 00 00 f0 fe 4b 08
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 2.5.54-bk1 + POSIX/HRT patches, with HIGH_RES_TIMERS=y:
> 
> kernel BUG at include/asm/spinlock.h:123!
> invalid operand: 0000
> CPU:    0
> EIP:    0060:[<c01307a0>]    Not tainted
> EFLAGS: 00010086
> EIP is at good_timespec+0x80/0x180
> eax: 0000000e   ebx: f68c589c   ecx: f6f96300   edx: c03e3aec
> esi: 87000007   edi: f6919ed8   ebp: f6919ec8   esp: f6919eb4
> ds: 007b   es: 007b   ss: 0068
> Process 2timer_test (pid: 1940, threadinfo=f6918000 task=f6bc6b80)
> Stack: c036a860 c0130784 00000023 f6919f30 00000001 f6919ee4 c01300b8 87000007
>        f6919ed8 00000086 00000023 f6919f30 f6919efc c0127117 f6919f30 f6919f30
>        f6bc7130 f6918000 f6919f1c c012829a f6bc7130 f6919f30 f6bc7130 f6919fc4
> Call Trace:
>  [<c0130784>] good_timespec+0x64/0x180
>  [<c01300b8>] schedule_next_timer+0x18/0x50
>  [<c0127117>] __dequeue_signal+0x87/0xa0
>  [<c012829a>] notify_parent+0x7a/0x290
>  [<c01092cd>] handle_signal+0x5d/0xd0
>  [<c0222e5f>] copy_to_user+0x2f/0x40
>  [<c01285ea>] do_no_restart_syscall+0x10a/0x240
>  [<c0109582>] work_resched+0x13/0x15
> 
> Code: 0f 0b 7b 00 04 a5 36 c0 59 58 8d b6 00 00 00 00 f0 fe 4b 08
> 
> ###
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
George Anzinger   george@mvista.com
High-res-timers: 
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml

      reply	other threads:[~2003-01-08  0:57 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-04  0:27 [PATCH 1/3] High-res-timers part 1 (core) take 23 george anzinger
2003-01-04  0:39 ` William Lee Irwin III
2003-01-04  0:58   ` george anzinger
2003-01-07 19:37 ` Randy.Dunlap
2003-01-08  0:05   ` george anzinger [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3E1B6B32.5D369127@mvista.com \
    --to=george@mvista.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rddunlap@osdl.org \
    --cc=torvalds@transmeta.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox