On Fri, 24 Aug 2018, Vlastimil Babka wrote:
>
> I think you can just post those for review and say that they apply on
> top of xarray git? Maybe also with your own git URL with those applied
> for easier access? I'm curious but also sceptical that something so
> major would get picked up to mmotm
On Fri, 24 Aug 2018, Vlastimil Babka wrote:
>
> I think you can just post those for review and say that they apply on
> top of xarray git? Maybe also with your own git URL with those applied
> for easier access? I'm curious but also sceptical that something so
> major would get picked up to mmotm
On 08/22/2018 07:40 PM, Christopher Lameter wrote:
> On Mon, 13 Aug 2018, Matthew Wilcox wrote:
>
>> Please consider pulling the XArray patch set. The XArray provides an
>> improved interface to the radix tree data structure, providing locking
>> as part of the API, specifying GFP flags at
On 08/22/2018 07:40 PM, Christopher Lameter wrote:
> On Mon, 13 Aug 2018, Matthew Wilcox wrote:
>
>> Please consider pulling the XArray patch set. The XArray provides an
>> improved interface to the radix tree data structure, providing locking
>> as part of the API, specifying GFP flags at
Hi Linus,
On Tue, 21 Aug 2018 19:09:31 -0700 Linus Torvalds
wrote:
>
> For some unfathomable reason, you have based it on the libnvdimm tree.
> I don't understand at all wjhy you did that.
That was partly my fault for giving not very good advice when the
(quite complex) merge conflict turned
Hi Linus,
On Tue, 21 Aug 2018 19:09:31 -0700 Linus Torvalds
wrote:
>
> For some unfathomable reason, you have based it on the libnvdimm tree.
> I don't understand at all wjhy you did that.
That was partly my fault for giving not very good advice when the
(quite complex) merge conflict turned
On Wed, Aug 22, 2018 at 11:23 AM Matthew Wilcox wrote:
>
> Dan added an entirely new function here:
>
> http://git.infradead.org/users/willy/linux-dax.git/commitdiff/c2a7d2a115525d3501d38e23d24875a79a07e15e
>
> which needed to be converted to XArray. So I should have pulled in his
> branch as a
On Wed, Aug 22, 2018 at 11:23 AM Matthew Wilcox wrote:
>
> Dan added an entirely new function here:
>
> http://git.infradead.org/users/willy/linux-dax.git/commitdiff/c2a7d2a115525d3501d38e23d24875a79a07e15e
>
> which needed to be converted to XArray. So I should have pulled in his
> branch as a
On Wed, Aug 22, 2018 at 10:43 AM Linus Torvalds
wrote:
>
> On Wed, Aug 22, 2018 at 10:40 AM Christopher Lameter wrote:
> >
> > Is this going in this cycle? I have a bunch of stuff on top of this to
> > enable slab object migration.
>
> No.
>
> It was based on a buggy branch that isn't getting
On Wed, Aug 22, 2018 at 10:43 AM Linus Torvalds
wrote:
>
> On Wed, Aug 22, 2018 at 10:40 AM Christopher Lameter wrote:
> >
> > Is this going in this cycle? I have a bunch of stuff on top of this to
> > enable slab object migration.
>
> No.
>
> It was based on a buggy branch that isn't getting
On Tue, Aug 21, 2018 at 08:00:18PM -0700, Linus Torvalds wrote:
> On Tue, Aug 21, 2018 at 7:50 PM Matthew Wilcox wrote:
> > So, should I have based just on your tree and sent you a description of
> > what a resolved conflict should look like?
>
> Absolutely.
>
> Or preferably not rebasing at
On Tue, Aug 21, 2018 at 08:00:18PM -0700, Linus Torvalds wrote:
> On Tue, Aug 21, 2018 at 7:50 PM Matthew Wilcox wrote:
> > So, should I have based just on your tree and sent you a description of
> > what a resolved conflict should look like?
>
> Absolutely.
>
> Or preferably not rebasing at
On Wed, Aug 22, 2018 at 10:40 AM Christopher Lameter wrote:
>
> Is this going in this cycle? I have a bunch of stuff on top of this to
> enable slab object migration.
No.
It was based on a buggy branch that isn't getting pulled, so when I
started looking at it, the pull request was rejected
On Wed, Aug 22, 2018 at 10:40 AM Christopher Lameter wrote:
>
> Is this going in this cycle? I have a bunch of stuff on top of this to
> enable slab object migration.
No.
It was based on a buggy branch that isn't getting pulled, so when I
started looking at it, the pull request was rejected
On Mon, 13 Aug 2018, Matthew Wilcox wrote:
> Please consider pulling the XArray patch set. The XArray provides an
> improved interface to the radix tree data structure, providing locking
> as part of the API, specifying GFP flags at allocation time, eliminating
> preloading, less re-walking the
On Mon, 13 Aug 2018, Matthew Wilcox wrote:
> Please consider pulling the XArray patch set. The XArray provides an
> improved interface to the radix tree data structure, providing locking
> as part of the API, specifying GFP flags at allocation time, eliminating
> preloading, less re-walking the
On Tue, Aug 21, 2018 at 7:50 PM Matthew Wilcox wrote:
>
> So, should I have based just on your tree and sent you a description of
> what a resolved conflict should look like?
Absolutely.
Or preferably not rebasing at all, just starting from a good solid
base for new development in the first
On Tue, Aug 21, 2018 at 7:50 PM Matthew Wilcox wrote:
>
> So, should I have based just on your tree and sent you a description of
> what a resolved conflict should look like?
Absolutely.
Or preferably not rebasing at all, just starting from a good solid
base for new development in the first
On Tue, Aug 21, 2018 at 07:09:31PM -0700, Linus Torvalds wrote:
> On Mon, Aug 13, 2018 at 9:14 AM Matthew Wilcox wrote:
> >
> > Please consider pulling the XArray patch set.
>
> So this merge window has been horrible, but I was just about to start
> looking at it.
>
> And no. I'm not going to
On Tue, Aug 21, 2018 at 07:09:31PM -0700, Linus Torvalds wrote:
> On Mon, Aug 13, 2018 at 9:14 AM Matthew Wilcox wrote:
> >
> > Please consider pulling the XArray patch set.
>
> So this merge window has been horrible, but I was just about to start
> looking at it.
>
> And no. I'm not going to
On Mon, Aug 13, 2018 at 9:14 AM Matthew Wilcox wrote:
>
> Please consider pulling the XArray patch set.
So this merge window has been horrible, but I was just about to start
looking at it.
And no. I'm not going to pull this.
For some unfathomable reason, you have based it on the libnvdimm
On Mon, Aug 13, 2018 at 9:14 AM Matthew Wilcox wrote:
>
> Please consider pulling the XArray patch set.
So this merge window has been horrible, but I was just about to start
looking at it.
And no. I'm not going to pull this.
For some unfathomable reason, you have based it on the libnvdimm
Hi Linus,
Please consider pulling the XArray patch set. The XArray provides an
improved interface to the radix tree data structure, providing locking
as part of the API, specifying GFP flags at allocation time, eliminating
preloading, less re-walking the tree, more efficient iterations and not
Hi Linus,
Please consider pulling the XArray patch set. The XArray provides an
improved interface to the radix tree data structure, providing locking
as part of the API, specifying GFP flags at allocation time, eliminating
preloading, less re-walking the tree, more efficient iterations and not
24 matches
Mail list logo
