linux-kernel - Re: [PATCH 3/9] [SCSI] mvsas: Add driver version and interrupt coalescing to device attributes in sysfs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110530144815.GB2689@kroah.com>
Date:	Mon, 30 May 2011 22:48:15 +0800
From:	Greg KH <greg@...ah.com>
To:	Xiangliang Yu <yuxiangl@...vell.com>
Cc:	"James.Bottomley@...e.de" <James.Bottomley@...e.de>,
	"jslaby@...e.cz" <jslaby@...e.cz>,
	"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Jacky Feng <jfeng@...vell.com>
Subject: Re: [PATCH 3/9] [SCSI] mvsas: Add driver version and interrupt
 coalescing to device 	attributes in sysfs

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@...vell.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/