From: Greg KH <greg@kroah.com>
To: Xiangliang Yu <yuxiangl@marvell.com>
Cc: "James.Bottomley@suse.de" <James.Bottomley@suse.de>,
"jslaby@suse.cz" <jslaby@suse.cz>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Jacky Feng <jfeng@marvell.com>
Subject: Re: [PATCH 3/9] [SCSI] mvsas: Add driver version and interrupt coalescing to device attributes in sysfs
Date: Mon, 30 May 2011 22:48:15 +0800 [thread overview]
Message-ID: <20110530144815.GB2689@kroah.com> (raw)
In-Reply-To: <F766E4F80769BD478052FB6533FA745D19FAD84CD9@SC-VEXCH4.marvell.com>
On Mon, May 30, 2011 at 04:22:40AM -0700, Xiangliang Yu wrote:
>
> >> >> +What: /sys/devices/pci/<devices>/<dev>/host/scsi_host/host/interrupt_coalescing
> >> >> +Date: May 2011
> >> >> +Kernel Version: 2.6.39
> >>
> >> >2.6.39 was released already, is this file in that release?
> >> Yes.
>
> >How, doesn't your patch below implement that option? How can it already
> >be in the .39 kernel?
> oh, that is my fault, I read the README and find out the misunderstanding of Kernel
> Version. How about 2.6.40?
There never will be such a kernel release number, sorry.
> >> >> +Contact: yuxiangl@marvell.com
> >> >> +Description: Determines the maximum time the 88SE94XX waits after the occurrence of a
> >> >> + Command Done before generating an interrupt.The maximum number of the
> >> >> + variable is less than 0x10000.
> >>
> >> >Why would a user, or anyone else, ever want to be able to change this?
> >> Because different platform can get better performance by setting different value
>
> >Then you need to document _how_ to do this tuning, and why someone would
> >want to, and lots of other stuff. Don't just blindly let userspace
> >change a value that they know nothing about.
> How about this HOW_TO: you can get a better I/O throughput by
> decreasing the value of Interrupt coalescing, or you can get a better
> CPU think time if you increase the value.
I still don't konw what you mean by this. And you really want the
ability to change this stepping by 0x10000 individual choices?
> >> >Why wouldn't this just be something that the driver handles
> > >>automagically so the user never has to worry about it at all?
> > >>As for now, driver can't do it. The value need to be test, and get the best.
> >Why don't you test it and set it to the proper value now? What would
> >change in a user's system that require this to be changed? Size of the
> >machine? Number of disks? Something else?
> >It really should be automatic, people do not ever want to have to
> >manually tune their machines anymore they should be smart enough to
> >determine the load on them and make the changes without any user needing
> >to do it for them.
> The default value is best for normal situation, but sometime user need
> to tune The value. For example, the system has more than 16 SATA SSD
> disks, CPU need more time to schedule other jobs while running I/O,
> but the user want to do lots of other jobs at the same time, so, the
> user can write a bigger number to the sysfs, the CPU can execute other
> jobs more quickly. This is a balance between CPU think time and I/O
> throughput. But the value is depend on the system environment, like
> as: disk number, what kind of platform, etc. Actually, the most
> important reason for tuning is what the user want, I/O throughput or
> think time.
But that's up to the block scheduler, not your driver, right? Why would
the driver matter here at all?
And again, 0x10000 different choices? That's crazy.
> By default, the value don't need to be changed.
Then I would strongly recommend never exporting this value to allow it
to be changed at all then. It doesn't sound worth it.
greg k-h
next prev parent reply other threads:[~2011-05-30 14:51 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mvsas-intr-coal>
2011-05-24 14:31 ` [PATCH 3/9] [SCSI] mvsas: Add driver version and interrupt coalescing to device attributes in sysfs yxlraid
2011-05-26 2:18 ` Greg KH
2011-05-26 9:00 ` Xiangliang Yu
2011-05-26 14:14 ` Greg KH
2011-05-27 3:23 ` Xiangliang Yu
2011-05-27 7:33 ` Greg KH
2011-05-30 7:26 ` Xiangliang Yu
2011-05-30 7:45 ` Greg KH
2011-05-30 11:22 ` Xiangliang Yu
2011-05-30 14:48 ` Greg KH [this message]
2011-05-31 7:26 ` Xiangliang Yu
2011-05-31 7:41 ` Greg KH
2011-05-31 8:52 ` Xiangliang Yu
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=20110530144815.GB2689@kroah.com \
--to=greg@kroah.com \
--cc=James.Bottomley@suse.de \
--cc=jfeng@marvell.com \
--cc=jslaby@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=yuxiangl@marvell.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