fail.
> >
> >
> This makes me wonder... If you replace the internal HD with a non IBM or
> IBM supported Hard Drive, will it still park the head and will it
> support all the stuff?
Depends, the drive must support the IDLE_IMMEDIATE unload subfeature, as
described in ata7
On Fri, Jul 08 2005, Jon Escombe wrote:
> Jens Axboe wrote:
>
> >On Thu, Jul 07 2005, Shawn Starr wrote:
> >
> >
> >>Model: HTS548080M9AT00 (Hitachi)
> >>Laptop: T42.
> >>
> >>segfault:/home/spstarr# ./a /dev/hda
> >>head park
On Fri, Jul 08 2005, Jens Axboe wrote:
> On Tue, Jul 05 2005, Linus Torvalds wrote:
> > So my gut feel is that the reason hdparm and dd from the raw partition
> > gives different performance is not so much the driver, but probably that
> > we've tweaked read-ahead fo
On Fri, Jul 08 2005, Andrew Morton wrote:
> Jens Axboe <[EMAIL PROTECTED]> wrote:
> >
> > Some more investigation - it appears to be broken read-ahead, actually.
> > hdparm does repeated read(), lseek() loops which causes the read-ahead
> > logic to mark the
On Fri, Jul 08 2005, Ingo Molnar wrote:
>
> * Jens Axboe <[EMAIL PROTECTED]> wrote:
>
> > But! I used hdparm -t solely, 2.6 was always ~5% faster than 2.4. But
> > using -Tt slowed down the hd speed by about 30%. So it looks like some
> > scheduler interaction
On Fri, Jul 08 2005, Steven Pratt wrote:
> Jens Axboe wrote:
>
> >On Fri, Jul 08 2005, Andrew Morton wrote:
> >
> >
> >>Jens Axboe <[EMAIL PROTECTED]> wrote:
> >>
> >>
> >>>Some more investigation - it appears to be broken
oded as:
void *kmem_cache_alloc_node(cachep, flags, node)
{
if (node != -1)
return __kmem_cache_alloc_node(cachep, flags, node);
/* no valid node, fall back to regular slab alloc */
return kmem_cache_alloc(cachep, flags);
}
--
Jens Axboe
-
To unsubscrib
On Tue, Jul 26 2005, Peter Osterlund wrote:
> Jens Axboe <[EMAIL PROTECTED]> writes:
>
> > On Sat, Jul 23 2005, Peter Osterlund wrote:
> > > Jens Axboe <[EMAIL PROTECTED]> writes:
> > >
> > > > Dunno why I didn't notice before, but
On Tue, Jul 26 2005, Adrian Bunk wrote:
> "extern inline" doesn't make much sense.
Yep, thanks.
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
I/O barrier handling.
Nice work! I'll review this, added to list...
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
opriate choice, you could still have read starvation
issues with noop. anticipatory doesn't make any sense, as the device has
no seek penalty.
and hey, don't top post! now we lost daves original mail.
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux-k
sed to a _GPL() export of, say, the sys_() interface?
I guess the sys_get/set export would be ok, although it seems a little
nasty to export the actual syscalls.
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
attached files appear to be corrupted, I cannot read them.
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
aded, right now you just can't unload as
and cfq because they use io contexts. But that will happen in the future
as well.
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
ked by duplicate calls to cfq_find_next_crq which ends
> up clearing cfqq->next_crq as, on the second call, last isn't on rb
> tree.
>
> This patch fixes cfq_find_next_crq() and removes extra calls to
> cfq_update_next_crq().
Thanks, looks good!
--
Jens Axboe
-
To unsubscribe
libata core support, adding NCQ support
to a sata_* driver should now be fairly trivial (with docs).
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kern
On Mon, Aug 01 2005, Jens Axboe wrote:
> On Mon, Aug 01 2005, Daniel Drake wrote:
> > Otto Meier wrote:
> > >My question is also are these features (NCQ/TCQ) and the heigher
> > >datarate be supported by this
> > >modification? or is only the basic f
On Mon, Aug 01 2005, Jeff Garzik wrote:
> Jens Axboe wrote:
> >On Mon, Aug 01 2005, Daniel Drake wrote:
> >
> >>Otto Meier wrote:
> >>
> >>>My question is also are these features (NCQ/TCQ) and the heigher
> >>>datarate be supported by th
On Mon, Aug 01 2005, Jeff Garzik wrote:
> Jens Axboe wrote:
> >Oh, and forget TCQ. It's a completely worthless technology inherited
> >from PATA,
>
> Agreed.
>
> There are a few controllers where we may -eventually- add TCQ support,
> controllers that do 100%
On Mon, Aug 01 2005, Jeff Garzik wrote:
> Jens Axboe wrote:
> >On Mon, Aug 01 2005, Jeff Garzik wrote:
> >
> >>Jens Axboe wrote:
> >>
> >>>Oh, and forget TCQ. It's a completely worthless technology inherited
> >>
> >>>from P
hardware max is 64K */
> AHCI_DMA_BOUNDARY = 0x,
> AHCI_USE_CLUSTERING = 0,
> AHCI_CMD_SLOT_SZ= 32 * 32,
Reasoning? I agree, just wondering... How big is the allocated area now?
--
Jens Axboe
-
To unsubscribe from this list: send the line "
t rather from
the blk_cleanup_queue() call when the reference count drops to 0).
This is still not perfect, but a lot better. Does it work for you?
--- linux-2.6.12/drivers/ide/ide-disk.c~2005-08-02 12:48:16.0
+0200
+++ linux-2.6.12/drivers/ide/ide-disk.c 2005-08-02 12:48:32
ktop anyway?
> This is basically a laptop issue.
Eh yes, very much.
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
intentionally used"?
I completely agree, that was my reading of the spec as well and hence my
original posts about this in the NCQ thread.
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majo
On Wed, Aug 03 2005, Martin Wilck wrote:
> Jens Axboe wrote:
>
> >>If I am reading the specs correctly, that'd mean the ahci driver is
> >>wrong in setting the SActive bit.
> >
> >I completely agree, that was my reading of the spec as well and hence m
nt index into it as well.
>
> It corrupts data with some MD setups.
>
> See http://bugzilla.kernel.org/show_bug.cgi?id=4946
>
> Hge thanks to Matthew Stapleton <[EMAIL PROTECTED]> for doggedly
> chasing this one down.
>
> Acked-by: Jens Axboe <[EMAIL
out to disk? ;)
>
> Emergency head parker needs to be pagelocked for other reasons. You do
> not want to page it from disk while your notebook is in free fall.
It's still a very bad idea imho, what if the head parker daemon is
killed for other reasons? The automatic timeout thawing
> thawing the drive based on current accelerometer data, rather than
> simply waking up after x seconds (maybe you're running for a bus rather
> than falling off a table)...
>
> To get the best of both worlds, could we maybe take a watchdog timer
> approach, and have the t
-storage had been manually removed (as you can see from the kernel
message), a few seconds later I removed power from the device and the
oopsed happened right then.
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTE
c/fstab to accomplish that (or do it manually, only
mentioning it for completeness).
--
Jens Axboe
diff -urpN -X /home/axboe/cdrom/exclude
/opt/kernel/linux-2.6.13-rc6-mm2/drivers/block/blktrace.c
linux-2.6.13-rc6-mm2/drivers/block/blktrace.c
--- /opt/kernel/linux-2.6.13-rc6-mm2/drivers/block/blktrace.c
On Wed, Aug 24 2005, Nathan Scott wrote:
> Hi Jens,
>
> On Tue, Aug 23, 2005 at 02:32:36PM +0200, Jens Axboe wrote:
> > ...
> > + t.pid = current->pid;
> > ...
> > +/*
> > + * The trace itself
> > + */
> > +struct blk_io_trace {
&
On Wed, Aug 24 2005, Nathan Scott wrote:
> On Tue, Aug 23, 2005 at 02:32:36PM +0200, Jens Axboe wrote:
> > Hi,
> >
> > This is a little something I have played with. It allows you to see
> > exactly what is going on in the block layer for a given queue. Currently
>
On Wed, Aug 24 2005, Nathan Scott wrote:
> On Wed, Aug 24, 2005 at 09:08:10AM +0200, Jens Axboe wrote:
> > ...
> > This isn't msec precision, it's usec. sched_clock() is in ns! I already
> > decided that msec is too coarse, but usec _should_ be enough.
>
>
On Wed, Aug 24 2005, Jens Axboe wrote:
> On Wed, Aug 24 2005, Nathan Scott wrote:
> > On Wed, Aug 24, 2005 at 09:08:10AM +0200, Jens Axboe wrote:
> > > ...
> > > This isn't msec precision, it's usec. sched_clock() is in ns! I already
> > > decided
_save(flags);
spin_lock(lock);
which is equivelant to spin_lock_irqsave() in mainline being illegal in
-RT, is that correct? This is what cfq uses right now for an exiting
task, as the above trace indicates.
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux-k
On Wed, Aug 24 2005, Esben Nielsen wrote:
> On Wed, 24 Aug 2005, Jens Axboe wrote:
>
> > On Wed, Aug 24 2005, Lee Revell wrote:
> > > Just found this in dmesg.
> > >
> > > BUG: scheduling with irqs disabled: libc6.postinst/0x2000/13229
&
On Thu, Aug 25 2005, Ingo Molnar wrote:
>
> * Jens Axboe <[EMAIL PROTECTED]> wrote:
>
> > > BUG: scheduling with irqs disabled: libc6.postinst/0x2000/13229
> > > caller is ___down_mutex+0xe9/0x1a0
> > > [] schedule+0x59/0xf0
On Thu, Aug 25 2005, Ingo Molnar wrote:
>
> * Jens Axboe <[EMAIL PROTECTED]> wrote:
>
> > There can quite easily be lots of pending IO for the io_context (and,
> > in CFQ's case, below cfq_io_contexts), task exiting is completely
> > decoupled from a
load
> /lib/modules/2.6.13-rc7/modules.dep: No such file or directory
> Aug 25 11:45:10 amd cardmgr[1429]: modprobe exited with status 1
> Aug 25 11:45:10 amd cardmgr[1429]: module //pcmcia/memory_cs.o not available
> Aug 25 11:45:10 amd cardmgr[1429]: bind 'memory_cs' to
a second or so for the park command
> to be issued if the disk was busy
That part seems to have been lost, apparently. The above patch is
correct.
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
gt;
> > Why is this needed?
>
> I think Jon discussed that in a previous thread, but basically
> although ide_next is documented in the comment for ide_do_drive_cmd,
> there isn't (as far as Jon or I could see) anything actually handling
> it. This patch is carried over from J
#x27;as' will need additional work to
be unloadable, but it wont break anything since it's running with an
elevated module count right now anyways.
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECT
On Mon, Aug 29 2005, Nathan Scott wrote:
> On Wed, Aug 24, 2005 at 11:28:39AM +0200, Jens Axboe wrote:
> > ...
> > Patch attached is against 2.6.13-rc6-mm2. Still a good idea to apply the
> > relayfs read update from the previous mail [*] as well.
>
> Hi Jens,
>
>
ince he's writing the io side
should look correct. I doubt 8 dd's writing 4k chunks will gobble that
much CPU as to make this much difference.
Holger, we need vmstat 1 info while the dd's are running. A simple
profile would be nice as well, boot with profile=2 and do a readprofile
imply use cfq and use the scsi_host scan sysfs
> attribute to scan "- - -" repeatedly on a scsi host and watch the memory
> vanish.
Yeah, that actually looks like a dangling reference. I assume you tested
this properly?
--
Jens Axboe
-
To unsubscribe from this list: send the lin
On Wed, Aug 31 2005, Nathan Scott wrote:
> Hi Jens,
>
> On Wed, Aug 24, 2005 at 11:28:39AM +0200, Jens Axboe wrote:
> > Patch attached is against 2.6.13-rc6-mm2. Still a good idea to apply the
> > relayfs read update from the previous mail [*] as well.
>
> There
On Wed, Aug 31 2005, Nathan Scott wrote:
> Hi Jens,
>
> On Wed, Aug 24, 2005 at 11:28:39AM +0200, Jens Axboe wrote:
> > Ok, updated version.
>
> One thing I found a bit awkward was the way its putting all inodes
> in the root of the relayfs namespace, with the cpuid ta
ultiples of the soft block size
> - reads and writes need to happen *at* multiples of the soft block size
Actually, the buffer only needs to be hard block size aligned, same goes
for the chunk size used for reads/writes.
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscri
On Wed, Aug 31 2005, Erik Mouw wrote:
> On Wed, Aug 31, 2005 at 10:07:45AM +0200, Jens Axboe wrote:
> > On Mon, Aug 29 2005, Erik Mouw wrote:
> > > There are four prerequisites for direct IO:
> > > - the file needs to be opened with O_DIRECT
> > > - the buffer
make much of a difference though,
feels like the problem is elsewhere (driver, most likely).
If we still can't get closer to this, it would be interesting to try my
block tracing stuff so we can see what is going on at the queue level.
But lets gather some more info first, since it requires testing -mm.
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Wed, Aug 31 2005, Brian King wrote:
> Jens Axboe wrote:
> > On Tue, Aug 30 2005, [EMAIL PROTECTED] wrote:
> >
> >>I ran across a memory leak related to the cfq scheduler. The cfq
> >>init function increments the refcnt of the associated request_queue.
>
q->nr_batching = cfq_queued;
> _
That looks better. I'll add this to my outgoing queue, thanks!
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Wed, Aug 31 2005, Holger Kiehl wrote:
> On Wed, 31 Aug 2005, Jens Axboe wrote:
>
> >Nothing sticks out here either. There's plenty of idle time. It smells
> >like a driver issue. Can you try the same dd test, but read from the
> >drives instead? Use a bigge
ou just wasted 1MiB of preallocated requests on each
queue in the system!
Please just do
# echo 512 > /sys/block/dev/queue/nr_requests
after boot for each device you want to increase the queue size too. 512
should be enough with the 3ware.
--
Jens Axboe
-
To unsubscribe from this list: send
r's problem, though, the reading
would be much faster if it was. If the fusion is using a large queue
depth, increasing nr_requests would likely help the writes (but not to
the extent of where it would suddenly be as fast as it should).
--
Jens Axboe
-
To unsubscribe from this list: send the l
ds as expected, like the buffered io but using less system time.
And you are still 1/3 off the target data rate, hmmm...
With the reads, how does the aggregate bandwidth look when you add
'clients'? Same as with writes, gradually decreasing per-device
throughput?
--
Jens Axboe
-
T
On Wed, Aug 31 2005, Nathan Scott wrote:
> Hi Jens,
>
> On Wed, Aug 24, 2005 at 11:28:39AM +0200, Jens Axboe wrote:
> > Ok, updated version.
>
> One thing I found a bit awkward was the way its putting all inodes
> in the root of the relayfs namespace, with the cpuid ta
On Tue, Sep 06 2005, Ravikiran G Thirumalai wrote:
> The following patchset breaks down the global ide_lock to per-hwgroup lock.
> We have taken the following approach.
Curious, what is the point of this?
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe l
On Wed, Sep 07 2005, Ravikiran G Thirumalai wrote:
> On Wed, Sep 07, 2005 at 11:19:24AM +0200, Jens Axboe wrote:
> > On Tue, Sep 06 2005, Ravikiran G Thirumalai wrote:
> > > The following patchset breaks down the global ide_lock to per-hwgroup
> > > lock.
> &
#x27;t cover all the needed
cases.
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
gt; these
> kernel_thread() users (like jffs2)...
>
> Any comment/suggestion?
Patch is correct, that is definitely an oversight!
Acked-by: Jens Axboe <[EMAIL PROTECTED]>
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ples that make the
mempool work. So the answer is 'yes' if you only reuse it a little, 'no'
if you want to hang on to it forever.
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED
) failed at net/ipv4/tcp_input.c (2148)
> Sep 8 17:15:40 ng02 kernel: [ 3242.103951] Leak l=4294967295 3
Same thing happens in -git from this morning.
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED
ction at all, if your system has both perhaps the driver got
left out?
A boot log from a working system would help a lot.
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http:/
called INITIALIZE STATUS ELEMENT
> WITH RANGE and again doesn't change the external state
> of the device.
>
> The patch is against lk 2.6.13 .
>
> Changelog:
> - mark SCSI opcode 0x37 (READ DEFECT DATA) as
> safe_for_read
>
> Signed-off-by: Dougla
-76,6 +85,7 @@ struct loop_device {
enum {
LO_FLAGS_READ_ONLY = 1,
LO_FLAGS_USE_AOPS = 2,
+ LO_FLAGS_FASTFS = 4,
};
#include/* for __kernel_old_dev_t */
@@ -159,5 +169,6 @@ int loop_unregister_transfer(int number);
#define LOOP_SET_STATUS6
On Wed, Jan 09 2008, Christoph Hellwig wrote:
> On Wed, Jan 09, 2008 at 09:52:32AM +0100, Jens Axboe wrote:
> > - The file block mappings must not change while loop is using the file.
> > This means that we have to ensure exclusive access to the file and
> > this is the
ways insist to reinvent everything? That's bad
enough in itself, but on top of that most of the extra stuff ends up
being essentially unmaintained.
If we instead improve loop, everyone wins.
Sorry to sound a bit harsh, but sometimes it doesn't hurt to think a bit
outside your own sandbox.
--
J
On Thu, Jan 10 2008, Nick Piggin wrote:
> On Wednesday 09 January 2008 19:52, Jens Axboe wrote:
>
> > So how does it work? Instead of punting IO to a thread and passing it
> > through the page cache, we instead attempt to send the IO directly to the
> > filesystem block t
On Thu, Jan 10 2008, Jens Axboe wrote:
> On Wed, Jan 09 2008, Alasdair G Kergon wrote:
> > Here's the latest version of dm-loop, for comparison.
> >
> > To try it out,
> > ln -s dmsetup dmlosetup
> > and supply similar basic parameters to losetup.
> &
On Wed, Jan 09 2008, Andi Kleen wrote:
> Jens Axboe <[EMAIL PROTECTED]> writes:
> >
> > So how does it work? Instead of punting IO to a thread and passing it
> > through the page cache, we instead attempt to send the IO directly to the
>
> Great -- something lik
einventing it.
Completely agree, it's just needed right now for this solution since all
we have is a crappy bmap() interface to get at those mappings.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Mo
On Thu, Jan 10 2008, Christoph Hellwig wrote:
> On Thu, Jan 10, 2008 at 09:44:57AM +0100, Jens Axboe wrote:
> > > IMHO this shouldn't be done in the loop driver anyway. Filesystems have
> > > their own effricient extent lookup trees (well, at least xfs and btrfs
> &g
;t even worst case for that size. It
also wastes memory by populating extents that we may never read or
write.
If you look at the loop addition I did, it populates lazily as needed
with some very simple logic to populate-ahead. In practice that performs
as well as a pre-populated map, the first IO to
On Thu, Jan 10 2008, Peter Zijlstra wrote:
>
> On Thu, 2008-01-10 at 10:49 +0100, Jens Axboe wrote:
> > On Thu, Jan 10 2008, Peter Zijlstra wrote:
> > >
> > > On Thu, 2008-01-10 at 08:37 +, Christoph Hellwig wrote:
> > >
> > > > Peter, any
On Thu, Jan 10 2008, Chris Mason wrote:
> On Thu, 10 Jan 2008 09:31:31 +0100
> Jens Axboe <[EMAIL PROTECTED]> wrote:
>
> > On Wed, Jan 09 2008, Alasdair G Kergon wrote:
> > > Here's the latest version of dm-loop, for comparison.
> > >
> >
On Thu, Jan 10 2008, Chris Mason wrote:
> On Thu, 10 Jan 2008 08:54:59 +
> Christoph Hellwig <[EMAIL PROTECTED]> wrote:
>
> > On Thu, Jan 10, 2008 at 09:44:57AM +0100, Jens Axboe wrote:
> > > > IMHO this shouldn't be done in the loop driver anyw
that the hw
has a way of being told not to reorder beyond the barrier, in which case
you don't have to drain the queue.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http:
ve noticed the warning on request_queue_t, surely. The big
problem is the last hunk here though, how would that work on stacked
devices? Clue: ->bi_bdev is not const, it can change after a call to
->make_request_fn().
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Mon, Dec 10 2007, Daniel Phillips wrote:
> On Monday 10 December 2007 02:47, Jens Axboe wrote:
> > Ehm, this patch is so broken it's not even funny - did you even
> > compile? You would have noticed the warning on request_queue_t,
> > surely. The big problem is the
On Mon, Dec 10 2007, Daniel Phillips wrote:
> On Monday 10 December 2007 03:41, Jens Axboe wrote:
> > On Mon, Dec 10 2007, Daniel Phillips wrote:
> > > + if (q && q->metric && !bio->bi_queue) {
> > >
> > > This
On Mon, Dec 10 2007, Daniel Phillips wrote:
> On Monday 10 December 2007 04:16, Jens Axboe wrote:
> > OK, let me get the neon out then. This has nothing to do with
> > throttling, I thought I made it clear that I get why you store the
> > origin queue in ->bi_queue. I'
On Mon, Dec 10 2007, Daniel Phillips wrote:
> On Monday 10 December 2007 04:32, Jens Axboe wrote:
> > I honestly don't know how to make this any clearer than I already did
> > above.
>
> Sure you do, you could cut out the rhetoric and save lots of bandwidth
> thereb
On Mon, Dec 10 2007, Daniel Phillips wrote:
> On Monday 10 December 2007 05:19, Jens Axboe wrote:
> > Precisely. So forgive me for thinking this patch hasn't seen very
> > varied testing, that's 2 errors (one simple, one bad - broken was NOT
> > a gross exagera
On Mon, Dec 10 2007, Daniel Phillips wrote:
> On Monday 10 December 2007 05:30, Jens Axboe wrote:
> > On Mon, Dec 10 2007, Daniel Phillips wrote:
> > "Let me close with perhaps the most relevant remarks: the attached
> > code has been in heavy testing and in production
vents (maybe even more, summed up
losely). I'm still not a big fan of the indirect stuff, but that's
minor.
You can get fio by doing a
$ git clone git://git.kernel.dk/fio.git
or just grabbing the latest snapshot from
http://brick.kernel.dk/snaps/fio-git-latest.tar.gz
--
Jens Axboe
--
To
t, then
we could look at getting some testing done.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Tue, Dec 11 2007, Daniel Phillips wrote:
> On Tuesday 11 December 2007 05:15, Jens Axboe wrote:
> > On Mon, Dec 10 2007, Daniel Phillips wrote:
> > > Now about that block writeout deadlock... it doesn't just affect my
> > > code, it basically breaks Linux as
On Wed, Dec 12 2007, Tejun Heo wrote:
> Jens Axboe wrote:
> > On Wed, Dec 05 2007, Tejun Heo wrote:
> >> Use msecs_to_jiffies() and jiffies_to_msecs() in scsi_ioctl().
> >> Sometimes callers use very large values for e.g. vendor specific media
> >> clear
bit of bio->bi_rw defined in bio.h is:
> #define BIO_RW_AHEAD 1
> but
> Second bit of rq->cmd_flags is __REQ_FAILFAST
>
> so maybe we are getting FAILFAST in the wrong places?
But that's actually on purpose, though the comment is pretty much crap.
We don't want
applied) patch detected! Assume -R? [n]
This is 2.6.24-rc5 (pretty close to at least, no changes to ll_rw_blk.c
from that version). Are you using quilt and forgot to refresh, or
something like that?
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel
here's little
point. I've applied your patch, thanks.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
r this to be a block layer problem if you do see
occasional segments being merged. So it sounds more like the input data
having changed.
Why not just bisect it?
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PR
On Thu, Dec 13 2007, Mark Lord wrote:
> Jens Axboe wrote:
> >On Thu, Dec 13 2007, Mark Lord wrote:
> >>Matthew Wilcox wrote:
> >>>On Thu, Dec 13, 2007 at 01:48:18PM -0500, Mark Lord wrote:
> >>>>Problem confirmed. 2.6.23.8 regularly generates seg
On Thu, Dec 13 2007, Mark Lord wrote:
> Mark Lord wrote:
> >Jens Axboe wrote:
> >>On Thu, Dec 13 2007, Mark Lord wrote:
> >>>Matthew Wilcox wrote:
> >>>>On Thu, Dec 13, 2007 at 01:48:18PM -0500, Mark Lord wrote:
> >>>>>Problem confi
On Thu, Dec 13 2007, Mark Lord wrote:
> Jens Axboe wrote:
> >On Thu, Dec 13 2007, Mark Lord wrote:
> >>Mark Lord wrote:
> >>>Jens Axboe wrote:
> >>>>On Thu, Dec 13 2007, Mark Lord wrote:
> >>>>>Matthew Wilcox wrote:
&g
On Thu, Dec 13 2007, Jens Axboe wrote:
> On Thu, Dec 13 2007, Mark Lord wrote:
> > Jens Axboe wrote:
> > >On Thu, Dec 13 2007, Mark Lord wrote:
> > >>Mark Lord wrote:
> > >>>Jens Axboe wrote:
> > >>>>On Thu, Dec 13 2007, Mark Lord
On Thu, Dec 13 2007, Mark Lord wrote:
> Jens Axboe wrote:
> >On Thu, Dec 13 2007, Mark Lord wrote:
> >>Jens Axboe wrote:
> >>>On Thu, Dec 13 2007, Mark Lord wrote:
> >>>>Mark Lord wrote:
> >>>>>Jens Axboe wrote:
> >>
On Thu, Dec 13 2007, Mark Lord wrote:
> Jens Axboe wrote:
> >On Thu, Dec 13 2007, Jens Axboe wrote:
> >>On Thu, Dec 13 2007, Mark Lord wrote:
> >>>Jens Axboe wrote:
> >>>>On Thu, Dec 13 2007, Mark Lord wrote:
> >>>>>Mark Lord wrote:
&g
On Thu, Dec 13 2007, Mark Lord wrote:
> Jens Axboe wrote:
> >On Thu, Dec 13 2007, Mark Lord wrote:
> >>Jens Axboe wrote:
> >>>On Thu, Dec 13 2007, Jens Axboe wrote:
> >>>>On Thu, Dec 13 2007, Mark Lord wrote:
> >>>>>Jens Axboe wrote:
&
901 - 1000 of 6207 matches
Mail list logo
