mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.com>
To: "Dilger\, Andreas" <andreas.dilger@intel.com>
Cc: James Simmons <jsimmons@infradead.org>, "Drokin\,
	Oleg" <oleg.drokin@intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Lustre Development List <lustre-devel@lists.lustre.org>
Subject: Re: [lustre-devel] [PATCH 11/17] staging: lustre: libcfs: discard cfs_time_shift().
Date: Thu, 05 Apr 2018 08:00:14 +1000	[thread overview]
Message-ID: <87tvsqy6mp.fsf@notabene.neil.brown.name> (raw)
In-Reply-To: <CB90FEDF-3F67-46A7-8EC3-ABC788E7978C@intel.com>

[-- Attachment #1: Type: text/plain, Size: 2547 bytes --]

On Wed, Apr 04 2018, Dilger, Andreas wrote:

> On Apr 2, 2018, at 16:26, NeilBrown <neilb@suse.com> wrote:
>> On Mon, Apr 02 2018, Dilger, Andreas wrote:
>>> On Mar 30, 2018, at 13:02, James Simmons <jsimmons@infradead.org> wrote:
>>>>> This function simply multiplies by HZ and adds jiffies.
>>>>> This is simple enough to be opencoded, and doing so
>>>>> makes the code easier to read.
>>>>> 
>>>>> Same for cfs_time_shift_64()
>>>> 
>>>> Reviewed-by: James Simmons <jsimmons@infradead.org>
>>> 
>>> Hmm, I thought we were trying to get rid of direct HZ usage in modules,
>>> because of tickless systems, and move to e.g. msecs_to_jiffies() or similar?
>> 
>> Are we?  I hadn't heard but I could easily have missed it.
>> Documentation/scheduler/completion.txt does say
>> 
>>    Timeouts are preferably calculated with
>>    msecs_to_jiffies() or usecs_to_jiffies().
>> 
>> but is isn't clear what they are preferred to.  Do you remember where
>> you heard? or have a reference?
>
> I thought the goal was to avoid hard-coding the HZ value so that kernels
> could have variable clock rates in the future.

It is hard to imagine it ever being possible to change, at runtime, the
length of time represented by one jiffie.
Durations, measured in jiffies, are stored it lots of different places,
and they would all need to be changed to msecs - very error prone work.
I think it would be much more likely to set HZ to some large value, and
have the clock tick at varying multiples of that.  The NOHZ work already
does something a bit like that I think.

Thanks,
NeilBrown

>
> Cheers, Andreas
>
>> $ git grep ' \* *HZ'  |wc
>>   2244   15679  170016
>> $ git grep msecs_to_jiffies | wc
>>   3301   13151  276725
>> 
>> so msecs_to_jiffies is slightly more popular than "* HZ" (even if you add
>> in "HZ *").  But that could just be a preference for using milliseconds
>> over using seconds.
>> 
>> $ git grep msecs_to_jiffies   | grep -c '[0-9]000'
>> 587
>> 
>> so there are only 587 places that msecs_to_jiffies is clearly used in
>> place of multiplying by HZ.
>> 
>> If we were to pursue this, I would want to add secs_to_jiffies() to
>> include/linux/jiffies.h and use that.
>> 
>> Thanks,
>> NeilBrown
>> _______________________________________________
>> lustre-devel mailing list
>> lustre-devel@lists.lustre.org
>> http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
>
> Cheers, Andreas
> --
> Andreas Dilger
> Lustre Principal Architect
> Intel Corporation

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

  reply	other threads:[~2018-04-04 22:00 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-29  4:26 [PATCH 00/17] staging: Assorted lustre cleanup NeilBrown
2018-03-29  4:26 ` [PATCH 15/17] staging: lustre: discard cfs_time_before_64() NeilBrown
2018-03-30 19:03   ` James Simmons
2018-03-29  4:26 ` [PATCH 01/17] staging: lustre: remove invariant in cl_io_read_ahead() NeilBrown
2018-03-30 18:56   ` James Simmons
2018-03-29  4:26 ` [PATCH 02/17] staging: lustre: remove unused ldlm_completion_ast_async() NeilBrown
2018-03-30 18:57   ` James Simmons
2018-03-29  4:26 ` [PATCH 09/17] staging: lustre: cfs_time_current() -> jiffies NeilBrown
2018-03-30 19:00   ` James Simmons
2018-03-29  4:26 ` [PATCH 11/17] staging: lustre: libcfs: discard cfs_time_shift() NeilBrown
2018-03-30 19:02   ` James Simmons
2018-04-02 19:34     ` Dilger, Andreas
2018-04-02 22:26       ` NeilBrown
2018-04-04  8:10         ` [lustre-devel] " Dilger, Andreas
2018-04-04 22:00           ` NeilBrown [this message]
2018-03-29  4:26 ` [PATCH 10/17] staging: lustre: libcfs: discard cfs_time_add/sub NeilBrown
2018-03-30 19:00   ` James Simmons
2018-03-29  4:26 ` [PATCH 12/17] staging: lustre: libcfs: discard cfs_time_after() NeilBrown
2018-03-30 19:01   ` James Simmons
2018-03-29  4:26 ` [PATCH 06/17] staging: lustre: tidy up ldlm_resource_putref() NeilBrown
2018-03-30 18:58   ` James Simmons
2018-03-29  4:26 ` [PATCH 03/17] staging: lustre: LNET excludes USERIO NeilBrown
2018-03-30 19:09   ` James Simmons
2018-03-29  4:26 ` [PATCH 14/17] staging: lustre: discard cfs_duration_sec() NeilBrown
2018-03-30 19:02   ` James Simmons
2018-03-29  4:26 ` [PATCH 16/17] staging: lustre: discard linux-time.h NeilBrown
2018-03-30 19:03   ` James Simmons
2018-03-29  4:26 ` [PATCH 08/17] staging: lustre: add container_of_safe() NeilBrown
2018-03-30 18:59   ` James Simmons
2018-04-23 13:16   ` Greg Kroah-Hartman
2018-03-29  4:26 ` [PATCH 04/17] staging: lustre: remove unused hash tables NeilBrown
2018-03-30 18:57   ` James Simmons
2018-03-29  4:26 ` [PATCH 17/17] staging: lustre: remove cruft from libcfs/linux/libcfs.h NeilBrown
2018-03-30 19:07   ` James Simmons
2018-03-29  4:26 ` [PATCH 13/17] staging: lustre: libcfs: remove cfs_timeout_cap() NeilBrown
2018-03-30 19:03   ` James Simmons
2018-04-02 19:38   ` Dilger, Andreas
2018-04-02 22:34     ` NeilBrown
2018-03-29  4:26 ` [PATCH 07/17] staging: lustre: ldlm: free resource when ldlm_lock_create() fails NeilBrown
2018-03-30 18:58   ` James Simmons
2018-03-29  4:26 ` [PATCH 05/17] staging: lustre: remove unneeded include NeilBrown
2018-03-30 18:57   ` James Simmons

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=87tvsqy6mp.fsf@notabene.neil.brown.name \
    --to=neilb@suse.com \
    --cc=andreas.dilger@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jsimmons@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lustre-devel@lists.lustre.org \
    --cc=oleg.drokin@intel.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

Powered by JetHome