On Mon, May 04, 2015 at 02:07:13PM +, Simmons, James A. wrote:
When is soon? How about, if I don't see some real work happening from
you all in the next 2 months (i.e. before 4.1-final), I drop lustre from
the tree in 4.2-rc1. Given that you all have had over 2 years to get
your
When is soon? How about, if I don't see some real work happening from
you all in the next 2 months (i.e. before 4.1-final), I drop lustre from
the tree in 4.2-rc1. Given that you all have had over 2 years to get
your act together, and nothing has happened, I think I've been waiting
Email chopped up and responded to out of order.
If this is acceptable to you it can be started right away.
No one is going to approve your patches until you send them. Start and
then we'll see. Send them in as they are ready so you don't get too far
along and we ask you to redo everything.
On Sat, 2 May 2015, Dan Carpenter wrote:
On Fri, May 01, 2015 at 09:13:11PM +, Drokin, Oleg wrote:
The patch was submitted.
But it depends on a symbol that's not exported.
I was not able to change that.
http://www.spinics.net/lists/linux-mm/msg83997.html
But you were
On Fri, May 01, 2015 at 09:13:11PM +, Drokin, Oleg wrote:
The patch was submitted.
But it depends on a symbol that's not exported.
I was not able to change that.
http://www.spinics.net/lists/linux-mm/msg83997.html
But you were given a hint on how to change that :)
Well, the
On Sat, May 02, 2015 at 01:18:48AM +, Simmons, James A. wrote:
Second and far more importantly the upstream lustre code
currently does not have the same level of QA with what the Intel
branch gets. The bar is very very high to get any patch merged for
the Intel branch. Each patch
Yes, I imagine Julia will include that as the new lustre_kvzalloc() define
to be used in all OBD_ALLOC_LARGE instances.
I can provide the desired code if necessary (it's actually a bit less than
trivial
because in some cases we also have that numa-aware node thing).
Oleg,
If you could send
On Sat, May 02, 2015 at 05:17:14PM +, Drokin, Oleg wrote:
Now I like to see the current situation change and Greg you have know
me for a while so you can expect a lot of changes are coming. In fact
I already have rallied people from vendors outside Intel as well as
universities which
Hello!
On May 2, 2015, at 4:26 AM, Greg Kroah-Hartman wrote:
On Sat, May 02, 2015 at 01:18:48AM +, Simmons, James A. wrote:
Second and far more importantly the upstream lustre code
currently does not have the same level of QA with what the Intel
branch gets. The bar is very very
Hello!
On May 2, 2015, at 4:14 AM, Dan Carpenter wrote:
On Fri, May 01, 2015 at 09:13:11PM +, Drokin, Oleg wrote:
The patch was submitted.
But it depends on a symbol that's not exported.
I was not able to change that.
http://www.spinics.net/lists/linux-mm/msg83997.html
But you were
Yes the LARGE functions do the switching. I was expecting also patches to
remove the
OBD_ALLOC_LARGE functions as well which is not the case here. I do have one
question still. The
macro __OBD_MALLOC_VERBOSE allowed the ability to simulate memory allocation
failures at
a certain
Yes the LARGE functions do the switching. I was expecting also patches to
remove the
OBD_ALLOC_LARGE functions as well which is not the case here. I do have one
question still. The
macro __OBD_MALLOC_VERBOSE allowed the ability to simulate memory allocation
failures at
a certain
We are hopefully going to get rid of OBD_ALLOC_LARGE() as well, though.
It's simple enough to write a function:
void *obd_zalloc(size_t size)
{
if (size 4 * PAGE_CACHE_SIZE)
return vzalloc(size);
else
return kmalloc(size, GFP_NOFS);
}
Except, huh?
On Fri, 1 May 2015, Simmons, James A. wrote:
From: Julia Lawall julia.law...@lip6.fr
Replace OBD_ALLOC, OBD_ALLOC_WAIT, OBD_ALLOC_PTR, and OBD_ALLOC_PTR_WAIT by
kalloc/kcalloc, and OBD_FREE and OBD_FREE_PTR by kfree.
Nak: James Simmons jsimm...@infradead.org
A simple replace will not
From: Julia Lawall julia.law...@lip6.fr
Replace OBD_ALLOC, OBD_ALLOC_WAIT, OBD_ALLOC_PTR, and OBD_ALLOC_PTR_WAIT by
kalloc/kcalloc, and OBD_FREE and OBD_FREE_PTR by kfree.
Nak: James Simmons jsimm...@infradead.org
A simple replace will not work. The OBD_ALLOC and OBD_FREE functions allocate
We are hopefully going to get rid of OBD_ALLOC_LARGE() as well, though.
It's simple enough to write a function:
void *obd_zalloc(size_t size)
{
if (size 4 * PAGE_CACHE_SIZE)
return vzalloc(size);
else
return kmalloc(size, GFP_NOFS);
}
Except, huh?
We are hopefully going to get rid of OBD_ALLOC_LARGE() as well, though.
It's simple enough to write a function:
void *obd_zalloc(size_t size)
{
if (size 4 * PAGE_CACHE_SIZE)
return vzalloc(size);
else
return kmalloc(size, GFP_NOFS);
}
Except,
On May 1, 2015, at 4:02 PM, Dan Carpenter wrote:
We are hopefully going to get rid of OBD_ALLOC_LARGE() as well, though.
It's simple enough to write a function:
void *obd_zalloc(size_t size)
{
if (size 4 * PAGE_CACHE_SIZE)
return vzalloc(size);
else
From: Julia Lawall julia.law...@lip6.fr
Replace OBD_ALLOC, OBD_ALLOC_WAIT, OBD_ALLOC_PTR, and OBD_ALLOC_PTR_WAIT by
kalloc/kcalloc, and OBD_FREE and OBD_FREE_PTR by kfree.
Nak: James Simmons jsimm...@infradead.org
A simple replace will not work. The OBD_ALLOC and OBD_FREE functions
On Fri, May 01, 2015 at 08:18:56PM +, Simmons, James A. wrote:
From: Julia Lawall julia.law...@lip6.fr
Replace OBD_ALLOC, OBD_ALLOC_WAIT, OBD_ALLOC_PTR, and OBD_ALLOC_PTR_WAIT
by
kalloc/kcalloc, and OBD_FREE and OBD_FREE_PTR by kfree.
Nak: James Simmons jsimm...@infradead.org
On May 1, 2015, at 4:18 PM, Simmons, James A. wrote:
Yes the LARGE functions do the switching. I was expecting also patches to
remove the
OBD_ALLOC_LARGE functions as well which is not the case here. I do have one
question still. The
macro __OBD_MALLOC_VERBOSE allowed the ability to
On Fri, May 01, 2015 at 08:36:05PM +, Simmons, James A. wrote:
We are hopefully going to get rid of OBD_ALLOC_LARGE() as well, though.
It's simple enough to write a function:
void *obd_zalloc(size_t size)
{
if (size 4 * PAGE_CACHE_SIZE)
return vzalloc(size);
Hello!
On May 1, 2015, at 1:48 PM, Julia Lawall wrote:
From: Julia Lawall julia.law...@lip6.fr
Replace OBD_ALLOC, OBD_ALLOC_WAIT, OBD_ALLOC_PTR, and OBD_ALLOC_PTR_WAIT by
kalloc/kcalloc, and OBD_FREE and OBD_FREE_PTR by kfree.
Nak: James Simmons jsimm...@infradead.org
A simple replace
On Fri, May 01, 2015 at 05:38:49PM +, Simmons, James A. wrote:
From: Julia Lawall julia.law...@lip6.fr
Replace OBD_ALLOC, OBD_ALLOC_WAIT, OBD_ALLOC_PTR, and OBD_ALLOC_PTR_WAIT by
kalloc/kcalloc, and OBD_FREE and OBD_FREE_PTR by kfree.
Nak: James Simmons jsimm...@infradead.org
A
On May 1, 2015, at 4:58 PM, Greg Kroah-Hartman wrote:
On Fri, May 01, 2015 at 08:52:37PM +, Drokin, Oleg wrote:
On May 1, 2015, at 4:49 PM, Greg Kroah-Hartman wrote:
On Fri, May 01, 2015 at 08:36:05PM +, Simmons, James A. wrote:
We are hopefully going to get rid of
On Fri, May 01, 2015 at 08:52:37PM +, Drokin, Oleg wrote:
On May 1, 2015, at 4:49 PM, Greg Kroah-Hartman wrote:
On Fri, May 01, 2015 at 08:36:05PM +, Simmons, James A. wrote:
We are hopefully going to get rid of OBD_ALLOC_LARGE() as well, though.
It's simple enough to write a
On May 1, 2015, at 4:49 PM, Greg Kroah-Hartman wrote:
On Fri, May 01, 2015 at 08:36:05PM +, Simmons, James A. wrote:
We are hopefully going to get rid of OBD_ALLOC_LARGE() as well, though.
It's simple enough to write a function:
void *obd_zalloc(size_t size)
{
if (size 4 *
27 matches
Mail list logo
