From: Matthew Wilcox
> From: Matthew Wilcox
> > Heh, I was thinking about that too. The radix tree supports "exceptional
> > entries" which have the bottom bit set. On a 64-bit machine, we could use
> 62
> > of the bits in the radix tree root to store the ID bitmap. I'm a little
> > wary of
>
On 12/17/2016 03:49 AM, Ming Lei wrote:
> If the last bvec of the 1st bio and the 1st bvec of the next
> bio are contineous physically, and the latter can be merged
> to last segment of the 1st bio, we should think they don't
> violate sg gap(or virt boundary) limit.
>
> Both Vitaly and Dexuan
On Fri, Dec 16 2016 at 5:29pm -0500,
Eric Wheeler wrote:
> On Wed, 14 Dec 2016, Eric Wheeler wrote:
> > Since dm-crypt queues writes (and sometimes reads) to a different kernel
> > thread (workqueue), the bios will dispatch from tasks with different
> >
From: Matthew Wilcox
> From: Rasmus Villemoes [mailto:li...@rasmusvillemoes.dk]
> > This sounds good. I think there may still be a lot of users that never
> > allocate more than a handful of IDAs, making a 128 byte allocation still
> > somewhat excessive. One thing I considered was (exactly as
Hi Guys,
On Sat, Oct 29, 2016 at 7:06 PM, kbuild test robot wrote:
> Hi Ming,
Thanks for the report!
>
> [auto build test ERROR on linus/master]
> [also build test ERROR on v4.9-rc2 next-20161028]
> [if your patch is applied to the wrong git tree, please drop us a note to
>
If the last bvec of the 1st bio and the 1st bvec of the next
bio are contineous physically, and the latter can be merged
to last segment of the 1st bio, we should think they don't
violate sg gap(or virt boundary) limit.
Both Vitaly and Dexuan reported lots of unmergeable small bios
are observed