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
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.
>
>> > 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
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
>
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
> >> universi
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 v
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
> > >
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
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 :)
>
> 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
>> >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, G
>> 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 c
>> 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 c
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 e
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)
>>> {
>>>
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 vzall
On Fri, May 01, 2015 at 08:18:56PM +, Simmons, James A. wrote:
> >> >From: Julia Lawall
> >> >
> >> >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
> >>
> >> A simp
>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);
>}
>
>Ex
>> >From: Julia Lawall
>> >
>> >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
>>
>> A simple replace will not work. The OBD_ALLOC and OBD_FREE functions
>> allocate memory
>> anyw
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
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
Hello!
On May 1, 2015, at 1:48 PM, Julia Lawall wrote:
>>> From: Julia Lawall
>>>
>>> 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
>>
>> A simple replace will not work. The OBD_
On Fri, May 01, 2015 at 05:38:49PM +, Simmons, James A. wrote:
> >From: Julia Lawall
> >
> >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
>
> A simple replace will not work. The O
>From: Julia Lawall
>
>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
A simple replace will not work. The OBD_ALLOC and OBD_FREE functions allocate
memory
anywhere from one page to 4MB in s
On Fri, 1 May 2015, Simmons, James A. wrote:
> >From: Julia Lawall
> >
> >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
>
> A simple replace will not work. The OBD_ALLOC and OBD_FREE
From: Julia Lawall
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.
A simplified version of the semantic patch that makes these changes is as
follows: (http://coccinelle.lip6.fr/)
//
@@ expression ptr,size; @@
-
28 matches
Mail list logo
