All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <jens.axboe@oracle.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 7/10] i386 sg: add support for chaining scatterlists
Date: Wed, 9 May 2007 12:28:35 +0200	[thread overview]
Message-ID: <20070509102835.GQ4163@kernel.dk> (raw)
In-Reply-To: <E1Hlj17-0001CJ-00@gondolin.me.apana.org.au>

On Wed, May 09 2007, Herbert Xu wrote:
> Jens Axboe <jens.axboe@oracle.com> wrote:
> > 
> > diff --git a/include/asm-i386/scatterlist.h b/include/asm-i386/scatterlist.h
> > index d7e45a8..794b68c 100644
> > --- a/include/asm-i386/scatterlist.h
> > +++ b/include/asm-i386/scatterlist.h
> > @@ -8,8 +8,11 @@ struct scatterlist {
> >     unsigned int       offset;
> >     dma_addr_t         dma_address;
> >     unsigned int       length;
> > +    struct scatterlist *next;
> > };
> 
> BTW, the crypto layer's scatterlist already has a chaining mechanism
> using the existing structure.  The only difference is that the chained
> pointer is stored inside the 'struct page *' rather than a new pointer.
> Its existence is flagged by a zero value in the length field.
> 
> Now I'm not super-religious about this but we should at least consider
> whether forking out 4 bytes in every scatterlist member is worthwhile
> investment when we can use 12 bytes at the end instead.

>From a memory consumption POV, it's definitely a win to reuse the ->page
member as a pointer to the next sgtable. I didn't do that originally to
avoid complications in allocating and setting up the sg table, but I may
very well reconsider that decision soonish.

We can easily change this without disturbing the upper layers, so it's
not a big deal to change now or later.

-- 
Jens Axboe


  parent reply	other threads:[~2007-05-09 10:32 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-09  7:59 [PATCH 0/10] Chaining sg lists for big IO commands v2 Jens Axboe
2007-05-09  7:59 ` [PATCH 1/10] crypto: don't pollute the global namespace with sg_next() Jens Axboe
2007-05-09  7:59 ` [PATCH 2/10] Add sg helpers for iterating over a scatterlist table Jens Axboe
2007-05-09  7:59 ` [PATCH 3/10] libata: convert to using sg helpers Jens Axboe
2007-05-09  7:59 ` [PATCH 4/10] block: " Jens Axboe
2007-05-09  7:59 ` [PATCH 5/10] scsi: " Jens Axboe
2007-05-09  7:59 ` [PATCH 6/10] i386 dma_map_sg: " Jens Axboe
2007-05-09  7:59 ` [PATCH 7/10] i386 sg: add support for chaining scatterlists Jens Axboe
2007-05-09 10:03   ` Herbert Xu
2007-05-09 10:19     ` Andrew Morton
2007-05-09 10:21       ` Herbert Xu
2007-05-09 10:30       ` Jens Axboe
2007-05-09 10:28     ` Jens Axboe [this message]
2007-05-09  7:59 ` [PATCH 8/10] scsi: simplify scsi_free_sgtable() Jens Axboe
2007-05-09  7:59 ` [PATCH 9/10] SCSI: support for allocating large scatterlists Jens Axboe
2007-05-09  7:59 ` [PATCH 10/10] ll_rw_blk: temporarily enable max_segments tweaking Jens Axboe
  -- strict thread matches above, loose matches on Subject: below --
2007-05-16  8:31 [PATCH 0/19] Chaining sg lists for big IO commands v6 Jens Axboe
2007-05-16  8:31 ` [PATCH 7/10] i386 sg: add support for chaining scatterlists Jens Axboe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070509102835.GQ4163@kernel.dk \
    --to=jens.axboe@oracle.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.