All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nishanth Aravamudan <nacc@us.ibm.com>
To: john stultz <johnstul@us.ibm.com>
Cc: lkml <linux-kernel@vger.kernel.org>,
	albert@users.sourceforge.net, paulus@samba.org,
	schwidefsky@de.ibm.com, mahuja@us.ibm.com, donf@us.ibm.com,
	mpm@selenic.com, benh@kernel.crashing.org
Subject: Re: [RFC][PATCH] new timeofday-based soft-timer subsystem
Date: Tue, 3 May 2005 10:02:24 -0700	[thread overview]
Message-ID: <20050503170224.GA2776@us.ibm.com> (raw)
In-Reply-To: <20050429233546.GB2664@us.ibm.com>

On 29.04.2005 [16:35:46 -0700], Nishanth Aravamudan wrote:
> * john stultz <johnstul@us.ibm.com> [2005-0429 15:45:47 -0700]:
> 
> > All,
> >         This patch implements the architecture independent portion of
> > the time of day subsystem. For a brief description on the rework, see
> > here: http://lwn.net/Articles/120850/ (Many thanks to the LWN team for
> > that clear writeup!)
> 
> I have been working closely with John to re-work the soft-timer subsytem
> to use the new timeofday() subsystem. The following patch attempts to
> being this process. I would greatly appreciate any comments.

I am not sure if anyone has looked at this patch closely, but I have
noticed one issue: My code assumes that all the rounding will be done
internally (rounding up on addition to find to the nearest
timerinterval); however, current interfaces do much of the rounding
before passing on structures on to the soft-timer subsystem, because the
jiffies-based one always rounds down.

This is most clear in sys_nanosleep(). Without any modifications to the
syscall, but with my patch applied, one will see around 5 millisecond
sleeps for a 1 millisecond request. This occurs, I believe, because
jiffies_to_timespec() rounds up once, we add one if there is any value
and then in internally I round up once more. If I rewrite
sys_nanosleep() to use schedule_timeout_nsecs() and thus never convert
from nanoseconds, I see 2 millisecond sleeps for 1 millisecond requests,
which is much closer (and accurate, as our granularity is slightly
greater than 1 millisecond and we are interruptiing at HZ=1000 slightly
more often than ever millisecond). This seems to be the right solution,
but then there is another issue: the restart_block used by
sys_nanosleep() only allows for 4 unsigned long arguments, when, in
fact, nanoseconds are a 64-bit quantity in the kernel. As long as the
nanosleep() request is no more than around 4 seconds, we should be ok
using unsigned longs. But anything longer will simply truncate
currently. I am not certain of a clean way to modify the restart_block
to incorporate a 64-bit quantity, as it is used by other interfaces as
well.

I still need to update the other version of nanosleep() (nsleep() and
posix) before I post an updated patch. Just wanted to let everyone know
of the issue.

Thanks,
Nish

  parent reply	other threads:[~2005-05-03 17:02 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-29 22:45 [RFC][PATCH (1/4)] new timeofday core subsystem (v A4) john stultz
2005-04-29 22:46 ` [RFC][PATCH (2/4)] new timeofday arch specific hooks " john stultz
2005-04-29 22:47   ` [RFC][PATCH (3/4)] new timeofday arch specific timesource drivers " john stultz
2005-04-29 22:48     ` [RFC][PATCH (4/4)] new timeofday vsyscall proof of concept " john stultz
2005-05-02 21:13   ` [RFC][PATCH (2/4)] new timeofday arch specific hooks " Pavel Machek
2005-05-02 21:28     ` john stultz
2005-04-29 23:35 ` [RFC][PATCH] new timeofday-based soft-timer subsystem Nishanth Aravamudan
2005-05-02 18:41   ` Darren Hart
2005-05-03 17:02   ` Nishanth Aravamudan [this message]
2005-05-03 17:22     ` Chris Friesen
2005-05-03 18:07       ` Nish Aravamudan
2005-05-03 21:47     ` Nishanth Aravamudan
2005-04-29 23:44 ` [RFC][PATCH (1/4)] new timeofday core subsystem (v A4) john stultz
2005-04-29 23:50 ` Benjamin Herrenschmidt
2005-04-30  0:33   ` john stultz

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=20050503170224.GA2776@us.ibm.com \
    --to=nacc@us.ibm.com \
    --cc=albert@users.sourceforge.net \
    --cc=benh@kernel.crashing.org \
    --cc=donf@us.ibm.com \
    --cc=johnstul@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mahuja@us.ibm.com \
    --cc=mpm@selenic.com \
    --cc=paulus@samba.org \
    --cc=schwidefsky@de.ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.