; I guess this fixes the setups with >4G of ram and 32bit pci cards as
> well (this also retains symmetry with the 32bit code).
>
> Signed-off-by: Andrea Arcangeli <[EMAIL PROTECTED]>
Thanks Andrea, this looks much saner!
--
Jens Axboe
On Fri, Sep 21 2007, Rusty Russell wrote:
> On Thu, 2007-09-20 at 14:27 +0200, Jens Axboe wrote:
> > On Thu, Sep 20 2007, Rusty Russell wrote:
> > > The block driver uses scatter-gather lists with sg[0] being the
> > > request information (struct virtio_blk_outhdr) with
On Fri, Sep 21 2007, Rusty Russell wrote:
> On Thu, 2007-09-20 at 15:05 +0200, Jens Axboe wrote:
> > On Thu, Sep 20 2007, Rusty Russell wrote:
> > > +static void end_dequeued_request(struct request *req,
> > > + struct req
4..4b24265 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -732,6 +732,7 @@ extern int end_that_request_chunk(struct request *, int,
int);
extern void end_that_request_last(struct request *, int);
extern void end_request(struct request *, int);
extern void end
ns success to userspace.
How about ever submitting a patch for that, instead of just repeatedly
complaining about it?
--
Jens Axboe
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visua
On Tue, Jun 12 2007, Rusty Russell wrote:
> On Tue, 2007-06-12 at 08:24 +0200, Jens Axboe wrote:
> > On Tue, Jun 12 2007, Rusty Russell wrote:
> > > On Mon, 2007-06-11 at 09:33 +0200, Jens Axboe wrote:
> > > > The other main request type is blk_pc_req
On Tue, Jun 12 2007, Rusty Russell wrote:
> On Mon, 2007-06-11 at 09:33 +0200, Jens Axboe wrote:
> > On Mon, Jun 11 2007, Rusty Russell wrote:
> > > So the problem is that I'd like to handle all of them, but I'm not clear
> > > what requests my device can ge
On Mon, Jun 11 2007, Rusty Russell wrote:
> On Mon, 2007-06-11 at 08:41 +0200, Jens Axboe wrote:
> > On Sun, Jun 10 2007, Rusty Russell wrote:
> > > On Sun, 2007-06-10 at 11:16 +0300, Avi Kivity wrote:
> > > > Rusty Russell wrote:
> > > > > Lguest d
atic int virtio_block_prep(request_queue_t *q, struct request *rq)
{
if (!blk_queue_start_tag(q, rq))
return BLKPREP_OK;
return BLKPREP_DEFER;
}
That is much easier to read, and as a bonus it wont eat your request
just because you run out
On Mon, Jun 04 2007, Carsten Otte wrote:
> Jens Axboe wrote:
> >Most people should not fiddle with it, the defaults are there for good
> >reason. I can provide a blk_queue_unplug_thresholds(q, depth, delay)
> >helper that you could use for the virtualized drivers, perhaps th
On Mon, Jun 04 2007, Rusty Russell wrote:
> On Mon, 2007-06-04 at 15:43 +0200, Jens Axboe wrote:
> > On Mon, Jun 04 2007, Carsten Otte wrote:
> > > Jens Axboe wrote:
> > > >On Fri, Jun 01 2007, Carsten Otte wrote:
> > > >>With regard to comp
On Mon, Jun 04 2007, Carsten Otte wrote:
> Jens Axboe wrote:
> >On Fri, Jun 01 2007, Carsten Otte wrote:
> >>With regard to compute power needed, almost none. The penalty is
> >>latency, not overhead: A small request may sit on the request queue to
> >>wai
;d greatly prefer maintaing a request_fn interface for this. The
make_request_fn/request_fn call ratio is at least 1, and typically a lot
larger (4kb blocks, 128kb request not uncommon -> 32).
--
Jens Axboe
-
This SF.net em
13 matches
Mail list logo