From: James Smart <James.Smart@Emulex.Com>
To: Joe Eykholt <jeykholt@cisco.com>
Cc: Vasu Dev <vasu.dev@linux.intel.com>,
"James.Bottomley@HansenPartnership.com"
<James.Bottomley@HansenPartnership.com>,
Christof Schmitt <christof.schmitt@de.ibm.com>,
"devel@open-fcoe.org" <devel@open-fcoe.org>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>
Subject: Re: [Open-FCoE] [PATCH v3] scsi-ml: adds queue_depth ramp up code
Date: Wed, 21 Oct 2009 09:11:18 -0400 [thread overview]
Message-ID: <4ADF0876.9070407@emulex.com> (raw)
In-Reply-To: <4ADE444D.5090307@cisco.com>
Joe Eykholt wrote:
> Vasu Dev wrote:
>> On Tue, 2009-10-20 at 20:54 +0200, Christof Schmitt wrote:
>>> I would prefer having seconds or milliseconds in sysfs and only using
>>> jiffies internally.
>>>
>> Added timestamp comparison checks are straightforward without any
>> additional conversion on each check since added timestamps and
>> queue_ramp_up_period both are jiffies, so works better this way with
>> stored queue_ramp_up_period in jiffies.
>>
>> I do see your point as well but jiffies unit is also common in Linux.
>> However if you or some other feels strongly to change this to ms or
>> seconds unit then I could change store or show sysfs functions to handle
>> this value in ms or second unit while storing it in jiffies in
>> queue_ramp_up_period.
>>
>> Vasu
>
> I agree with Christof on this, HZ may be 100 on some machines and 1000
> on others. Management tools (if they ever adjust this) would like
> standard units, so it should be in ms or seconds, and I prefer ms.
> I would just change the sysfs functions as you say, and use jiffies internally.
>
> Joe
I'll third this request - specifying in jiffies is a non-distinct value from
platform to platform. ms or seconds is preferred.
-- james
next prev parent reply other threads:[~2009-10-21 13:11 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-16 0:46 [PATCH v2 1/7] scsi-ml: modify change_queue_depth to take in reason why it is being called Vasu Dev
[not found] ` <20091016004639.22451.76363.stgit-M4Lc0Xp98oKtqXYlAKuG4QC/G2K4zDHf@public.gmane.org>
2009-10-16 0:46 ` [PATCH v2 2/7] scsi error: have scsi-ml call change_queue_depth to handle QUEUE_FULL Vasu Dev
2009-10-16 0:46 ` [PATCH v2 3/7] libfc: convert libfc calling scsi_track_queue_full Vasu Dev
2009-10-16 0:46 ` [PATCH v2 4/7] fcoe, libfc: fix an libfc issue with queue ramp down in libfc Vasu Dev
2009-10-16 0:47 ` [PATCH v2 5/7] scsi-ml: adds queue_depth ramp up code Vasu Dev
[not found] ` <20091016004700.22451.42962.stgit-M4Lc0Xp98oKtqXYlAKuG4QC/G2K4zDHf@public.gmane.org>
2009-10-16 9:29 ` Christof Schmitt
[not found] ` <20091016092912.GA7199-VuU8Q2ydlaqCpDFQwvYvMTJtLkR7yuzc@public.gmane.org>
2009-10-16 18:16 ` Vasu Dev
2009-10-16 23:08 ` [PATCH v3] " Vasu Dev
[not found] ` <20091016230824.18916.84116.stgit-M4Lc0Xp98oKtqXYlAKuG4QC/G2K4zDHf@public.gmane.org>
2009-10-20 18:54 ` Christof Schmitt
2009-10-20 22:32 ` Vasu Dev
2009-10-20 23:14 ` [Open-FCoE] " Joe Eykholt
[not found] ` <4ADE444D.5090307-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
2009-10-21 7:49 ` Christof Schmitt
2009-10-21 17:45 ` [Open-FCoE] " Vasu Dev
[not found] ` <20091021074944.GA3563-VuU8Q2ydlaqCpDFQwvYvMTJtLkR7yuzc@public.gmane.org>
2009-10-21 17:54 ` Giridhar Malavali
2009-10-21 13:11 ` James Smart [this message]
2009-10-21 13:37 ` Michael Reed
2009-10-22 22:46 ` [PATCH v4 5/7] " Vasu Dev
2009-10-23 13:53 ` Christof Schmitt
2009-10-23 17:51 ` Giridhar Malavali
2009-10-16 0:47 ` [PATCH v2 6/7] libfc: adds queue_depth ramp up to libfc Vasu Dev
2009-10-16 0:47 ` [PATCH v2 7/7] zfcp: Adapt change_queue_depth for queue full tracking Vasu Dev
2009-10-28 22:48 ` [PATCH v2 1/7] scsi-ml: modify change_queue_depth to take in reason why it is being called James Bottomley
[not found] ` <1256770118.2989.24.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2009-10-29 1:43 ` Vasu Dev
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=4ADF0876.9070407@emulex.com \
--to=james.smart@emulex.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=christof.schmitt@de.ibm.com \
--cc=devel@open-fcoe.org \
--cc=jeykholt@cisco.com \
--cc=linux-scsi@vger.kernel.org \
--cc=vasu.dev@linux.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 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.