linux-kernel - Re: What's in linux-2.6-block.git for 2.6.24

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 21 Sep 2007 02:15:05 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Jens Axboe <jens.axboe@...cle.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: What's in linux-2.6-block.git for 2.6.24

On Fri, 21 Sep 2007 10:57:11 +0200 Jens Axboe <jens.axboe@...cle.com> wrote:

> Hi,
> 
> This details the contents of the block git repo of items that are bound
> for a 2.6.24 merge. The SCSI data buffer accessor patch from Tomo will
> also be going in through the block tree, but it's not merged up yet.
> That's mainly due to my laziness, not because the code isn't ready. That
> will happen sometime during today.
> 
> Misc bits:
> - Various bug fixes from Neil Brown, part of his larger patchset for
>   allowing arbitrarily sized bios.
> - Various little bug fixes and documentation updates.
> 
> Barriers:
> - The empty bio barrier patches from me. These allow sending down a bio
>   with no data attached, for insertion a barrier in a request queue.
>   They are useful for dm and md, but also cleans up the sync
>   blkdev_issue_flush() interface - it's now no longer an addon hack, but
>   just a natural use of empty bio barriers.

That sounds useful.

> SG chaining bits:
> - This is the bulk of the patchset. It consists of three major
>   components:
> 
>         - sglist-core, which add helpers for iterating sg lists and
>           switches the block layer and SCSI to use those. Should not
>           have any functional changes.
>         - sglist-drivers, which converts drivers to use the sg list
>           helpers. Again, should not contain functional changes.
>         - sglist-arch, which adds support to most architectures and
>           actually enables sg chaining.
> 
> The goal of sg chaining is to allow support for very large sgtables,
> without requiring that they be allocated from one contigious piece of
> memory.

Presumably sg chaining means more overhead on the IO submission paths?  If
so, has this been quantified?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/