On Tue, Feb 19, 2008 at 09:16:44AM +1100, David Chinner wrote:
> On Mon, Feb 18, 2008 at 04:24:27PM +0300, Michael Tokarev wrote:
> > First, I still don't understand why in God's sake barriers are "working"
> > while regular cache flushes are not. Almost no consumer-grade hard drive
> > supports w
On Mon, Feb 11, 2008 at 04:22:11PM +1100, David Chinner wrote:
>
> What I think Nick is referring to is the comments I made that at a
> higher layer (e.g. filesystems) migrating completions to the
> submitter CPU may be exactly the wrong thing to do. I don't recall
> making any comments on migrati
On Thu, Aug 30, 2007 at 06:00:26PM -0700, Gaston, Jason D wrote:
> >
> >Resend without wordwrap.
> >
> >This patch adds the Intel Tolapai RAID controller DID's for SATA support.
> >
> >Signed-off-by: Jason Gaston <[EMAIL PROTECTED]>
> >
> >--- linux-2.6.23-rc4/drivers/ata/ahci.c.orig 2007-08-27
>
On Wed, Aug 22, 2007 at 09:39:36AM +0200, Jes Sorensen wrote:
> James Bottomley wrote:
> >On Tue, 2007-08-21 at 17:34 -0700, [EMAIL PROTECTED] wrote:
> >>The term "posted DMA" is used to describe this behavior in the Altix
> >>Device Driver Writer's Guide, but it may be confusing things here.
> >
On Wed, Aug 22, 2007 at 06:09:48PM -0700, Jeremy Higdon wrote:
> > I traced the pci_alloc_consistent calls from PrimeIocFifos on my
> > system. There are two calls for each ioc. The first is for
> > 266368 bytes, the second for 16320 bytes.
> >
> > I wonder w
On Wed, Aug 22, 2007 at 05:05:54PM -0700, Luck, Tony wrote:
> > Hmm. Must be something else going on then. It should be less than 1MB
> > per ioc plus whatever is used for streaming I/O.
> >
> > | mptbase: Initiating ioc2 bringup | GSI 16
> > (level, low) -> CPU 2 (0
On Wed, Aug 22, 2007 at 04:27:09PM -0700, Luck, Tony wrote:
> > The more ioc's you have, the more space you will use.
>
> Default SW IOTLB allocation is 64MB ... how much should we see
> used per ioc?
Hmm. Must be something else going on then. It should be less than 1MB
per ioc plus whatever i
On Wed, Aug 22, 2007 at 03:56:57PM -0700, Luck, Tony wrote:
> [ 20.903201] [] swiotlb_full+0x50/0x120
> [ 20.903202] sp=e0014322fac0 bsp=e00143229120
> [ 20.916902] [] swiotlb_map_single+0x120/0x1c0
> [ 20.916904] sp=e0014322fac0 bsp=e001432290d8
> [ 20.931215] [] swiotlb_alloc_cohe
On Mon, May 28, 2007 at 02:48:45PM +1000, Timothy Shimmin wrote:
> I'm taking it that the FUA write will just guarantee that that
> particular write has made it to disk on i/o completion
> (and no write cache flush is done).
Correct. It only applies to that one write command.
jeremy
-
To unsubsc
On Thu, Apr 26, 2007 at 11:50:33PM +1000, David Chinner wrote:
> On Thu, Apr 26, 2007 at 04:10:32AM -0600, Eric W. Biederman wrote:
> > > And then there's the problem that most hardware is limited to 128
> > > s/g entries and that means 128 non-contiguous pages in memory is the
> > > maximum I/O si
On Mon, Jan 08, 2007 at 05:09:34PM -0800, Paul Jackson wrote:
> Jeff wrote:
> > Something I just thought of: ATA and SCSI hard disks do their own
> > read-ahead.
>
> Probably this is wishful thinking on my part, but I would have hoped
> that most of the read-ahead they did was for stuff that happ
On Tue, Jan 02, 2007 at 02:50:53PM +0100, Jens Axboe wrote:
> Yep, I suspect this patch is long overdue. Jeremy, is this enough to fix
> it for you?
Yes, the 7 second timeout is fine. It actually takes about 6.7 seconds.
I guess if "another popular OS" has a 7 second timeout that we won't find
mu
I have a DVD combo drive and a CD in which the
"READ TRACK INFORMATION" command (implemented in the
cdrom_get_track_info() function) takes about 7 seconds to run.
The current implementation of cdrom_get_track_info() uses the
default timeout of 5 seconds. So here's a patch that increases
the timeou
On Fri, Apr 08, 2005 at 08:56:43AM +0100, Christoph Hellwig wrote:
> On Fri, Apr 08, 2005 at 12:23:46AM -0700, Jeremy Higdon wrote:
> > Even if it's deprecated, wouldn't it be good to fix it as long as
> > it's there, unless it hurts something else? Or at least f
On Thu, Apr 07, 2005 at 12:24:12PM +0100, Christoph Hellwig wrote:
> On Thu, Apr 07, 2005 at 01:21:23PM +0200, Hannes Reinecke wrote:
> > > /proc/scsi/scsi is deprecated and even only compiled in if
> > > "legacy /proc/scsi/ support" is enabled. Please move over to lssci which
> > > is using sysfs
On Fri, Mar 25, 2005 at 09:52:17PM -0600, James Bottomley wrote:
> On Thu, 2005-03-24 at 16:57 -0700, Moore, Eric Dean wrote:
> > +static struct device_attribute mptscsih_queue_depth_attr = {
> > + .attr = {
> > + .name = "queue_depth",
> > + .mode =
So I understand the point about filesystems and values that always happen
to be a power of two where the compiler can't know that.
However:
> From: [EMAIL PROTECTED] (Linus Torvalds)
>
> >So what we've said is: 64 bit is okay, except in a switch statement,
> >or other random expressions that mi
On Sep 19, 8:39am, Richard Henderson wrote:
>
> On Tue, Sep 19, 2000 at 12:22:41PM +0200, Andreas Schwab wrote:
> > IMHO it's a bug in gcc that it does not inline the comparison inside the
> > switch expression, since it already does it in all other places. Perhaps
> > some problem with the pat
> - Linux developers often do horribly stupid things, and use 64-bit
>division etc instead of using a simple shift. Again, not linking
>against libgcc finds those things early rather than late, because the
>horribly stupid things end up requireing libgcc support.
I would have thought
On Sep 19, 10:35am, Eric Youngdale wrote:
>
> OK, my guess is that we may need to do some tweaking to the Makefile.
> The basic idea is that you need to probe for hosts in a specific order.
> The reason for this is that some host adapters emulate other types of
> hardware. For example, some
On Sep 19, 1:08pm, Matti Aarnio wrote:
>
> On Tue, Sep 19, 2000 at 02:58:01AM -0700, Jeremy Higdon wrote:
> > Hello,
> >
> > I'm using a 64 bit variable in a switch statement. Gcc is generating code
> > which make calls to __ucmpdi2, a function defined in
Hello,
I'm using a 64 bit variable in a switch statement. Gcc is generating code
which make calls to __ucmpdi2, a function defined in libgcc. I figured
out that it was the switch statement from examining the generated code.
The question is whether I should change C code to avoid constructions
22 matches
Mail list logo
