t; at least one or possibly both of the file descriptors are unknown to the
> application anyway. Probably it'd be better to close them off immediately.
I agree with the solution, closing the descriptors that do_pipe() opened
is clearly the right thing to do.
> This would be an applicat
On Thu, Dec 13 2007, Andrew Morton wrote:
> On Thu, 13 Dec 2007 21:09:59 +0100
> Jens Axboe <[EMAIL PROTECTED]> wrote:
>
> >
> > OK, it's a vm issue,
>
> cc linux-mm and probable culprit.
>
> > I have tens of thousand "backward" pages
l.org/lkml/2007/10/27/61
>
> and addressed a panic after a umount reported by Sebastian Siewior. Was
> this addressed in some other way?
Yes, the below wasn't a proposal for inclusion, the problem got fixed
differently by commit 51fd77bd9f512ab6cc9df0733ba1caaab89eb957
--
Jens Ax
viously the problem doesn't occur if the limited cgroup performs read
> operations only.
>
> I'm posting the modified patch below only for discussion purposes, you
> could test it if you want, but you've been warned that the whole system
> could hang for certain amounts
On Sun, Jan 20 2008, Andrea Righi wrote:
> Jens Axboe wrote:
> > Your approach is totally flawed, imho. For instance, you don't want a
> > process to be able to dirty memory at foo mb/sec but only actually
> > write them out at bar mb/sec.
>
> Right. Actually my pr
s work was originally started by Nikanth Karthikesan
<[EMAIL PROTECTED]>, but then later completely reworked by me.
The patches are against latest -git.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECT
From: Nikanth Karthikesan <[EMAIL PROTECTED]>
changes in the cfq for io_context sharing
Signed-off-by: Jens Axboe <[EMAIL PROTECTED]>
---
block/cfq-iosched.c | 20 ++--
1 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/block/cfq-iosched.c b/block/c
this type of
lookup where the key is a pointer. It's a very sparse tree.
Signed-off-by: Jens Axboe <[EMAIL PROTECTED]>
---
block/cfq-iosched.c | 267 +
block/ll_rw_blk.c | 41 +---
include/linux/iocontext.h |6
Detach task state from ioc, instead keep track of how many processes
are accessing the ioc.
Signed-off-by: Jens Axboe <[EMAIL PROTECTED]>
---
block/ll_rw_blk.c | 27 ---
fs/ioprio.c |1 -
include/linux/blkdev.h|2 +-
include
This is where it belongs and then it doesn't take up space for a
process that doesn't do IO.
Signed-off-by: Jens Axboe <[EMAIL PROTECTED]>
---
block/cfq-iosched.c | 34 +--
block/ll_rw_blk.c | 42 ---
fs/ioprio.c
changes to anticipatory io scheduler for io_context sharing
Signed-off-by: Jens Axboe <[EMAIL PROTECTED]>
---
block/as-iosched.c | 34 --
1 files changed, 28 insertions(+), 6 deletions(-)
diff --git a/block/as-iosched.c b/block/as-iosched.c
index c
syslets can set this to enforce sharing of io context.
Signed-off-by: Jens Axboe <[EMAIL PROTECTED]>
---
include/linux/sched.h |1 +
kernel/fork.c | 14 ++
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/s
On Tue, Jan 22 2008, Peter Zijlstra wrote:
>
> On Tue, 2008-01-22 at 10:49 +0100, Jens Axboe wrote:
> > Hi,
> >
> > Today io contexts are per-process and define the (surprise) io context
> > of that process. In some situations it would be handy if several
> >
= jiffies;
diff --git a/fs/ioprio.c b/fs/ioprio.c
index 06b5d97..c4a1c3c 100644
--- a/fs/ioprio.c
+++ b/fs/ioprio.c
@@ -85,8 +85,6 @@ asmlinkage long sys_ioprio_set(int which, int who, int ioprio)
break;
case IOPRIO_CLASS_IDLE:
- if (!capable(CAP
On Wed, Jan 23 2008, Andrew Morton wrote:
> > On Tue, 22 Jan 2008 10:49:16 +0100 Jens Axboe <[EMAIL PROTECTED]> wrote:
> > This is where it belongs and then it doesn't take up space for a
> > process that doesn't do IO.
> >
> > ...
> >
> &g
On Wed, Jan 23 2008, Andrew Morton wrote:
> > On Tue, 22 Jan 2008 10:49:19 +0100 Jens Axboe <[EMAIL PROTECTED]> wrote:
> > The io context sharing introduced a per-ioc spinlock, that would protect
> > the cfq io context lookup. That is a regression from the original, since
On Wed, Jan 23 2008, Andrew Morton wrote:
> > On Tue, 22 Jan 2008 10:49:17 +0100 Jens Axboe <[EMAIL PROTECTED]> wrote:
> > -void put_io_context(struct io_context *ioc)
> > +int put_io_context(struct io_context *ioc)
> > {
> > if (ioc == NULL)
> > -
On Tue, Oct 02 2007, Benjamin Herrenschmidt wrote:
>
> On Mon, 2007-10-01 at 13:59 +0200, Jens Axboe wrote:
> > On Sun, Sep 30 2007, Grant Likely wrote:
> > > On 9/30/07, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> > > > On Sun, Sep 30, 2007
7 @@ COMPATIBLE_IOCTL(BLKSECTSET)
COMPATIBLE_IOCTL(BLKSSZGET)
COMPATIBLE_IOCTL(BLKTRACESTART)
COMPATIBLE_IOCTL(BLKTRACESTOP)
-COMPATIBLE_IOCTL(BLKTRACESETUP)
+HANDLE_IOCTL(BLKTRACESETUP32, blktrace32_setup)
COMPATIBLE_IOCTL(BLKTRACETEARDOWN)
ULONG_IOCTL(BLKRASET)
ULONG_IOCTL(BLKFRASET)
--
J
On Tue, Oct 02 2007, Arnd Bergmann wrote:
> On Tuesday 02 October 2007, Jens Axboe wrote:
> >
> > The layout of struct blk_user_trace_setup is a bit unfortunate, it gets
> > padded differently on 32-bit and 64-bit archs. So right now it's not
> > possible to trace
ial_struct32 {
@@ -2555,7 +2593,7 @@ COMPATIBLE_IOCTL(BLKSECTSET)
COMPATIBLE_IOCTL(BLKSSZGET)
COMPATIBLE_IOCTL(BLKTRACESTART)
COMPATIBLE_IOCTL(BLKTRACESTOP)
-COMPATIBLE_IOCTL(BLKTRACESETUP)
+HANDLE_IOCTL(BLKTRACESETUP32, blktrace32_setup)
COMPATIBLE_IOCTL(BLKTRACETEARDOWN)
ULONG_IOCTL(BLKR
IO scheduler being used for both the volume being used to perform the
> test on, as well as the one used for storing blk traces (when enabled).
> Right now I was using the default CFQ, when perhaps NOOP or DEADLINE would
> be a better choice. If there is enough interest in seeing ho
On Wed, Oct 03 2007, Grant Likely wrote:
> Jens,
>
> Here are some more Sysace patches based on comments received on the
> first series and a run through sparse. Can you please queue them up
> for 2.6.24?
Applied all 3, looked fine to me.
--
Jens Axboe
-
To unsubscribe from
mq->req;
unsigned int sg_len;
- if (!mq->bounce_buf)
- return blk_rq_map_sg(mq->queue, mq->req, mq->sg);
+ if (!mq->bounce_buf) {
+ memset(mq->sg, 0, rq->nr_hw_segments * sizeof(struct
scatterlist));
+ return blk_rq_map_sg
ave to do is put back the check for use_sg == 1
> > > and send
> > > > that as a bulk transfer command.
> > >
> > > Sorry about this. Can this fix the problem?
> > >
> > > Thanks,
> > >
> > >
> > > diff --git a/drivers/scsi/megaraid.c
> > > b/drivers/scsi/megaraid.c index 3907f67..da56163 100644
> > > --- a/drivers/scsi/megaraid.c
> > > +++ b/drivers/scsi/megaraid.c
> > > @@ -1753,6 +1753,14 @@ mega_build_sglist(adapter_t *adapter,
> > > scb_t *scb, u32 *buf, u32 *len)
> > >
> > > *len = 0;
> > >
> > > + if (scsi_sg_count(cmd) == 1 && !adapter->has_64bit_addr) {
> > > + sg = scsi_sglist(cmd);
> > > + scb->dma_h_bulkdata = sg_dma_address(sg);
> > > + *buf = (u32)scb->dma_h_bulkdata;
> > > + *len = sg_dma_len(sg);
> > > + return 0;
> > > + }
> > > +
> > > scsi_for_each_sg(cmd, sg, sgcnt, idx) {
> > > if (adapter->has_64bit_addr) {
> > > scb->sgl64[idx].address = sg_dma_address(sg);
> > >
> >
> >
> > With this patch I see the correct logical disk size reported.
> > Thanks.
>
> Great, thanks for testing!
>
> Can you try the following patch instead of the above patch?
>
> http://marc.info/?l=linux-scsi&m=119137033016550&w=2
>
>
> I know the changes are pretty trivial and it should work...
Tomo, this is the patch I added.
--
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 Thu, Oct 04 2007, Pierre Ossman wrote:
> On Thu, 4 Oct 2007 09:25:15 +0200
> Jens Axboe <[EMAIL PROTECTED]> wrote:
>
> >
> > It looks like missing init of the sg list in mmc, does this work?
> >
>
> Huh? Isn't the block layer supposed to fill i
On Thu, Oct 04 2007, Pierre Ossman wrote:
> On Thu, 4 Oct 2007 10:06:32 +0200
> Jens Axboe <[EMAIL PROTECTED]> wrote:
>
> > On Thu, Oct 04 2007, Pierre Ossman wrote:
> > >
> > > Huh? Isn't the block layer supposed to fill in the entire thing?
&
On Thu, Oct 04 2007, FUJITA Tomonori wrote:
> On Thu, 4 Oct 2007 09:28:34 +0200
> Jens Axboe <[EMAIL PROTECTED]> wrote:
>
> > On Thu, Oct 04 2007, FUJITA Tomonori wrote:
> > > On Wed, 3 Oct 2007 17:32:55 -0600
> > > &q
On Thu, Oct 04 2007, Pierre Ossman wrote:
> On Thu, 4 Oct 2007 11:30:14 +0200
> Jens Axboe <[EMAIL PROTECTED]> wrote:
>
> > On Thu, Oct 04 2007, Pierre Ossman wrote:
> > >
> > > I assume sg_init_one() still can work on an uninitialized sg entry?
> &g
On Thu, Oct 04 2007, Pierre Ossman wrote:
> On Thu, 4 Oct 2007 12:38:05 +0200
> Jens Axboe <[EMAIL PROTECTED]> wrote:
>
> > On Thu, Oct 04 2007, Pierre Ossman wrote:
> > >
> > > Is that a yes or a no? You said that the ->page field was involved
> &g
On Thu, Oct 04 2007, FUJITA Tomonori wrote:
> On Thu, 4 Oct 2007 12:48:58 +0200
> Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> > On Thu, Oct 04, 2007 at 09:28:34AM +0200, Jens Axboe wrote:
> > >...
> > > Tomo, this is the patch I added.
> >
> >
e, host->max_hw_segs);
blk_queue_max_segment_size(mq->queue, host->max_seg_size);
- mq->sg = kmalloc(sizeof(struct scatterlist) *
+ mq->sg = kzalloc(sizeof(struct scatterlist) *
host->max_phys_segs, GFP_KERNEL);
On Thu, Oct 04 2007, Don Mullis wrote:
> That patch boots without complaint as well.
>
> BTW, the earlier failure messages did not make it
> into /var/log/messages, only the dmesg buffer.
> This is with standard Ubuntu Gutsy logging levels.
Super, thanks for retesting!
--
J
PRM32, FDDEFPRM32 and FDGETPRM32 are doing potentially dangerous
> stuff with kernel pointers. sparse actually warns about this, but
> from what I could see from floppy.c, the kernel always ignores these
> pointers. I did not check any other floppy drivers implementing the
> same calls
like to second Davids emails here, this is a serious problem. Having
a reproducible test case lowers the barrier for getting the problem
fixed by orders of magnitude. It's the difference between the problem
getting fixed in a day or two and it potentially lingering for months,
because email pin
On Fri, Oct 05 2007, Pekka Enberg wrote:
> Hi,
>
> On 10/5/07, Jens Axboe <[EMAIL PROTECTED]> wrote:
> > I'd like to second Davids emails here, this is a serious problem. Having
> > a reproducible test case lowers the barrier for getting the problem
> >
nd the whole thing?
>
> I did the large patch on top of the blktrace patch I sent earlier,
> so it doesn't apply cleanly. When doing the final version, I'll use
> a more sensible patch order.
Ah I see, can you generate one against current git?
--
Jens Axboe
-
To unsub
On Fri, Oct 05 2007, Matthew Wilcox wrote:
> On Fri, Oct 05, 2007 at 08:48:53AM +0200, Jens Axboe wrote:
> > I'd like to second Davids emails here, this is a serious problem. Having
> > a reproducible test case lowers the barrier for getting the problem
> > fixed by ord
ks pretty good. I'll toss it in the tester and see if
things still work.
--
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 Fri, Oct 05 2007, Andi Kleen wrote:
> Jens Axboe <[EMAIL PROTECTED]> writes:
> >
> > Writing a small test module to exercise slub/slab in various ways
> > (allocating from all cpus freeing from one, as described) should not be
> > too hard. Perhaps that would b
s a lot Arnd! Applied 1-7 (with v2 of patch #1).
--
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/
our analysis does look correct. Does it work with this simple
patch?
diff --git a/include/linux/libata.h b/include/linux/libata.h
index 2784163..0152bf4 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -947,7 +947,7 @@ ata_sg_is_last(struct scatterlist *sg, struct
ata_queued_cmd *qc)
On Thu, Oct 11 2007, Tejun Heo wrote:
> Jens Axboe wrote:
> > This is the old ata_sg_is_last:
> >
> > static inline int
> > ata_sg_is_last(struct scatterlist *sg, struct ata_queued_cmd *qc)
> > {
> > if (sg == &qc->pad_sgent)
> >
On Fri, Dec 21 2007, Jens Axboe wrote:
> static void gdrom_readdisk_dma(struct work_struct *work)
> {
> ...
>
> read_command = kzalloc(sizeof(struct packet_command), GFP_KERNEL);
> if (!read_command)
> probably just defer the wo
e for every
command also seems pretty pointless, so move that outside the loop.
What is pages doing in gdrom_request()?
Your design is also heavily geared towards there just being a single
CDROM, I'm assuming this wont be a problem given your hw (it sets a bad
example for others to follow though
On Fri, Dec 21 2007, Adrian McMenamin wrote:
> On 21/12/2007, Jens Axboe <[EMAIL PROTECTED]> wrote:
> >
> > Your design is also heavily geared towards there just being a single
> > CDROM, I'm assuming this wont be a problem given your hw (it sets a bad
> > exa
On Fri, Dec 21 2007, Adrian McMenamin wrote:
> On Fri, December 21, 2007 2:22 pm, Jens Axboe wrote:
> > On Fri, Dec 21 2007, Adrian McMenamin wrote:
> >> On 21/12/2007, Jens Axboe <[EMAIL PROTECTED]> wrote:
> >> >
> >> > Your design is also
On Fri, Dec 21 2007, Adrian McMenamin wrote:
>
> On Fri, 2007-12-21 at 13:14 +0100, Jens Axboe wrote:
>
> >
> > What is pages doing in gdrom_request()?
> >
>
> As the device doesn't do scatter-gather I've set
> blk_queue_max_segment_size to 1 and
s. The kerneldoc comment for that
function also tells you NOT to use this in new code. Use
end_dequeued_request() and get rid of the requeue, and streamline 'err'
so you can just pass it directly in.
The locking otherwise looks fine to me.
--
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/
>
> I'm seeing the same thing here, on a similar machine ( 6459CTO ). I
> pulled the source from kernel git last night to test it.
>
>
> Bios:
> thinkpad_acpi: ThinkPad BIOS 7LET56WW (1.26 ), EC 7KHT22WW-1.06
I reported the same thing yesterday:
http://lkml.org/lkml/200
ectures. I'll look into this.
You should continue to do your own chaining if it's a requirement for
the driver/layer to function, until we get rid of ARCH_HAS_SG_CHAIN.
That'll happen when all archs are converted.
So don't rely on scatterlist helping you with chaining just yet, so
s the Silicon Image driver doing the wrong
> thing, or is DASD doing the wrong thing, or is BIO_RW_FAILFAST
> under-specified and we really need multiple flags or what?
Hrmpf. It looks like the SCSI layer is a little too trigger happy. Any
chance you could try and trace where this happens?
--
Jens A
post -
> Changes between take2 and take3:
> o Rebased on top of 2.6.24-rc3-mm2
OK, so this means that I can't apply it unfortunately. It depends on
other patches in -mm (bidi).
SCSI sits on block, so the best approach imho is to base this patchset
on mainline so
)?
> If there's no problem, could you merge it to your tree?
> Or does it have to be merged to -mm tree first?
Looks good to me now, I'll queue it up. Thanks!
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
Acked-by: Nick Piggin <[EMAIL PROTECTED]>
Goodie, I'll apply this one 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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
anges at once, I'll merge them into blk_end_request patch-set.
Twice the merging is not an issue for me.
> As for the patch inclusion, do you push the driver changes to Linus
> all at once? Or should I ask each maintainer to take the patch?
Lets just try to get as many maintainer acks as p
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 command and calculation can overflow.
Thanks Tejun, applied.
--
Jens Axboe
--
To unsubscribe from
s case?
> They should probably be kept in synch where possible...
Aaron sent a similar patch for deadline a while ago, so this just
matches them up again. I acked that patch, it makes a lot of sense to
me.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-ker
BLKPREP_DEFER;
> - /*
> - * Return failfast requests immediately
> - */
> - if (req->cmd_flags & REQ_FAILFAST)
> - ret = BLKPREP_KILL;
> + if (!(req
; +#ifdef CONFIG_BLK_DEV_IO_TRACE
> blk_add_trace_rq(cmd->rq->q, cmd->rq, BLK_TA_COMPLETE);
> +#endif /* CONFIG_BLK_DEV_IO_TRACE */
> blk_complete_request(cmd->rq);
> }
Puzzled by this patch... What is it trying to achieve?
--
Jens Axboe
-
To unsubscribe from this list: se
On Tue, Nov 20 2007, FUJITA Tomonori wrote:
> pci-noop.c doesn't use DMA mappings.
you should send that one to the alpha maintainers, it needs to go in
that way.
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message t
On Tue, Nov 20 2007, FUJITA Tomonori wrote:
> Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
applied
--
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 htt
On Thu, Nov 22 2007, Jerome Marchand wrote:
> Fix a memory leak in alloc_disk_node(). Don't forget to free 'dkstats'
> when the allocation of 'part' failed.
Thanks, applied.
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux
}
> + sg_init_table(mq->sg, host->max_phys_segs);
> }
>
> init_MUTEX(&mq->thread_sem);
Applied
--
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/
ack, I use it all the time for testing. Just because you don't
happen to use it is not a reason to remove it.
--
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.k
On Sun, Nov 25 2007, Adrian Bunk wrote:
> On Sun, Nov 25, 2007 at 05:21:07PM +0100, Jens Axboe wrote:
> > On Sun, Nov 25 2007, Adrian Bunk wrote:
> > > There isn't any big advantage and doesn't seem to be much usage of
> > > modular schedulers.
> >
On Sun, Nov 25 2007, Adrian Bunk wrote:
> On Sun, Nov 25, 2007 at 05:45:32PM +0100, Jens Axboe wrote:
> > On Sun, Nov 25 2007, Adrian Bunk wrote:
> > > On Sun, Nov 25, 2007 at 05:21:07PM +0100, Jens Axboe wrote:
> > > > On Sun, Nov 25 2007, Adrian Bunk wrote:
chaining.
>
> Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
> ---
> While converting libata to use chained-sg, I felt a bit insecure and
> added a few more safe guards. Feel free to include or ignore them.
Looks sane, thanks Tejun! Will apply it.
--
Jens Axboe
-
To unsubsc
t; Jens said he applied it, so I figured the issue was handled. Jens,
> what happened to it?
It's in my for-linus branch, it was applied when I wrote that reply. So
it's going upstream, the pull request has been sent to Linus.
My error here was not updating the for-akpm branch
acpi_processor_get_throttling_ptc+0x122/0x1a0 [processor]
[] acpi_processor_get_throttling+0x8/0x9 [processor]
[] acpi_processor_throttling_seq_show+0x29/0x137 [processor]
[<7816732d>] vma_link+0x5d/0xf0
[<7819089d>] seq_read+0x9d/0x290
[<78190800>] seq_read+0x0/0x290
[<
d move other unrelated blocks which
> would result in desychronized block map and corruption of both
> filesystems.
Please read the posted patch and the posts from Chris as well, it
basically covers everything in your email.
The patch, as posted, doesn't work if the fs moves blocks arou
these unexported because they are unstable and not yet considered
> suitable for use, or simply because nobody's written a module that
> splice()s yet?
The latter, I generally don't export things until they are used.
__splice_from_pipe() wasn't exported until some file s
blktrace is getting the proper timestamps now with
> CONFIG_NO_HZ.
Thanks for reporting this. Guillaume, did you write this patch? We need
to get it into 2.6.24-rc7 asap. Let me know if I should take care of
that, or if it's already queued up elsewhere.
--
Jens Axboe
--
To unsubscrib
th are unused for chain entry. Clear them.
>*/
> - prv->offset = 0;
> - prv->length = 0;
> + prv[prv_nents - 1].offset = 0;
> + prv[prv_nents - 1].length = 0;
>
> /*
>* Set lowest bit to indicate a link pointer, and make sure to clear
On Fri, Jan 11 2008, Ingo Molnar wrote:
>
> * Jens Axboe <[EMAIL PROTECTED]> wrote:
>
> > Thanks for reporting this. Guillaume, did you write this patch? We
> > need to get it into 2.6.24-rc7 asap. Let me know if I should take care
> > of that, or if it's
at, or if it's already queued up elsewhere.
> >
> > they are from the scheduler git tree (except the first debug patch),
> > but queued up for v2.6.25 at the moment.
>
> some of them are not - Guillaume has not sent them. I'll sort it out.
Thanks Ingo!
--
Je
On Fri, Jan 11 2008, Ingo Molnar wrote:
>
> * Jens Axboe <[EMAIL PROTECTED]> wrote:
>
> > > they are from the scheduler git tree (except the first debug patch),
> > > but queued up for v2.6.25 at the moment.
> >
> > So this means that blktrace wil
up(&msb->q_wait);
} else {
while ((req = elv_next_request(q)) != NULL)
end_queued_request(req, -ENODEV);
}
which is simpler and gets all cases correct. Reordering for normal case
as well.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscr
On Fri, Jan 11 2008, Ingo Molnar wrote:
>
> (David, could you try the patch further below - does it fix bkltrace
> timestamps too?)
>
> * Jens Axboe <[EMAIL PROTECTED]> wrote:
>
> > On Fri, Jan 11 2008, Ingo Molnar wrote:
> > >
>
On Fri, Jan 11 2008, Jens Axboe wrote:
> > ktime_get() should have been used instead, which is a proper GTOD
> > clocksource. The patch below implements this.
>
> Will give it a whirl, it looks promising indeed and gets rid of the ugly
> cpu sync stuff. What is the cost of
> > Jens already got back to you, but I can confirm it works here as well.
>
> great, thanks for testing it. (i'm not sure Jens saw the same issues as
> you, so your test was useful too.)
Right, I merely checked that ktime_get() worked for me.
--
Jens Axboe
--
To unsubscrib
On Fri, Jan 11 2008, Ingo Molnar wrote:
>
> * Jens Axboe <[EMAIL PROTECTED]> wrote:
>
> > > > If blktrace worked in 2.6.23 and it doesn't in 2.6.24 because of
> > > > some option that isn't immediately apparent, then it's a
> >
On Fri, Jan 11 2008, Daniel Phillips wrote:
> Hi Jens,
>
> This looks really useful.
>
> On Wednesday 09 January 2008 00:52, Jens Axboe wrote:
> > Disadvantages:
> >
> > - The file block mappings must not change while loop is using the
> > file. This means
> >
> >
> >
>
> Unfortunately, there was one small mistake (a repeated assignment), in
> the patch posted yesterday. Here is a corrected version.
>
> Signed-off by: Adrian McMenamin <[EMAIL PROTECTED]>
The io handling looks ok to me now.
Acke
__blk_end_request() directly.
Please just keep them both and call __blk_end_request(), it's nicer as
an exported name. Then we can do a cleanup run afterwards.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
ons for drivers. If you enable that and
your driver suddenly stops working, you have a clear idea of WHY it
stops working and how to fix it. Not so with this blktrace scenario, I
bet that would take people quite a while to figure out how it broke.
Can we drop this subject now, please? The issue is res
atives have all been slower though, so not
very tempting to transition to.
> No need for silly name calling here.
I don't know what thread you are reading, but neiter Ingo nor I have
resorted to silly name calling. The thread has long since diverted from
the original topic, though.
--
; +
> > + dst = kmap_atomic(page, KM_USER1);
> > + memcpy(dst + offset, src, copy);
> > + kunmap_atomic(dst, KM_USER1);
>
> You're using kmap_atomic, but I see no reason you can't be preempted.
> Don't you need to at least disable preemption wh
/
enum {
@@ -72,9 +71,6 @@
struct gendisk *lo_disk;
struct list_headlo_list;
- struct prio_tree_root prio_root;
- struct prio_tree_node *last_insert;
- struct prio_tree_node *last_lookup;
unsigned intblkbits;
};
--
On Mon, Jan 14 2008, Jens Axboe wrote:
> On Mon, Jan 14 2008, Chris Mason wrote:
> > Hello everyone,
> >
> > Here is a modified version of Jens' patch. The basic idea is to push
> > the mapping maintenance out of loop and down into the filesystem (ext2
>
On Tue, Jan 15 2008, Jens Axboe wrote:
> On Mon, Jan 14 2008, Jens Axboe wrote:
> > On Mon, Jan 14 2008, Chris Mason wrote:
> > > Hello everyone,
> > >
> > > Here is a modified version of Jens' patch. The basic idea is to push
> > > the
On Tue, Jan 15 2008, Jens Axboe wrote:
> On Tue, Jan 15 2008, Jens Axboe wrote:
> > On Mon, Jan 14 2008, Jens Axboe wrote:
> > > On Mon, Jan 14 2008, Chris Mason wrote:
> > > > Hello everyone,
> > > >
> > > > Here is a modified version
ot use sleeping functions like GFP_KERNEL allocations or
wait_event(). The other is that it's illegal to sleep from your
request_fn context in the first place, since you could be stalling
others.
- You also seem to be busy waiting for other transactions to finish. Any
idea how long those might take? Perhaps put an upper bound on this
waiting, and/or do blocking waits?
- I'm assuming this hardware can't do sg transfers?
--
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/
> then we might save one or two atomic operations per request.
>
> Anyway, I'm not completely sure if I have ensured all queue_flags users are
> safe (I think md may need a bit of help). But overall it seems quite doable.
Looks ok to me, I'll throw it into the testing mix
On Tue, Dec 18 2007, Nick Piggin wrote:
> On Tue, Dec 18, 2007 at 08:44:40AM +0100, Jens Axboe wrote:
> > On Sat, Dec 15 2007, Nick Piggin wrote:
> > > Hi,
> > >
> > > This is just an idea I had, which might make request processing a little
> > >
ants
> to create them.
The current code looks like that to minimize impact on 2.6.24, see this
branch:
http://git.kernel.dk/?p=linux-2.6-block.git;a=shortlog;h=sg
for how it folds into lib/sg.c and the magic disappears from SCSI.
Rusty, nobody claimed the sg code in 2.6.24 is perfect. I like
f.
Agree, and the missing bit is just moving the creators out of the driver
parts and into a core helper. See the previous post on the 'sg' branch
for 2.6.25.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
On Thu, Dec 20 2007, Bartlomiej Zolnierkiewicz wrote:
>
> * Move lba_to_msf() and msf_to_lba() to
> (use 'u8' type instead of 'byte' while at it).
>
> * Remove msf_to_lba() copy from drivers/cdrom/cdrom.c.
>
> Cc: Jens Axboe <[EMAIL PROTECTED]
On Mon, Jan 28 2008, Greg KH wrote:
> On Mon, Jan 28, 2008 at 09:49:35PM +0100, Jens Axboe wrote:
> > Hi,
> >
> > Running latest -git (head 91525300baf162e83e923b09ca286f9205e21522) and
> > connecting my cf usb storage device yields and endless stream of:
> >
On Tue, Jan 29 2008, Oliver Neukum wrote:
> Am Dienstag, 29. Januar 2008 15:11:08 schrieb Jens Axboe:
> > On Tue, Jan 29 2008, Boaz Harrosh wrote:
> > > On Tue, Jan 29 2008 at 15:54 +0200, Jens Axboe <[EMAIL PROTECTED]> wrote:
> > > > On Tue, Jan 29 2008, Boaz H
1001 - 1100 of 6207 matches
Mail list logo
