On Thu, 2 Apr 2015, Andrew Morton wrote:
> hm, OK. The per-allocator wrappers could be made static inline in .h
> if that makes sense.
The allocators will add code to the "per-allocator wrappers". Inlining
that would be bad. Basicalkly the "wrapper" is the skeleon to which
optimizations can be
On Thu, 2 Apr 2015, Andrew Morton wrote:
hm, OK. The per-allocator wrappers could be made static inline in .h
if that makes sense.
The allocators will add code to the per-allocator wrappers. Inlining
that would be bad. Basicalkly the wrapper is the skeleon to which
optimizations can be added
On Thu, 2 Apr 2015 09:25:37 -0500 (CDT) Christoph Lameter
wrote:
> > What's the reason for returning a partial result when ENOMEM? Some
> > callers will throw away the partial result and simply fail out. If a
> > caller attempts to go ahead and use the partial result then great, but
> > you
On Tue, 31 Mar 2015, Andrew Morton wrote:
> This patch doesn't really do anything. I guess nailing down the
> interface helps a bit.
Right.
> to modules. And it isn't completely obvious, because the return
> semantics are weird.
Ok.
> What's the reason for returning a partial result when
On Thu, 2 Apr 2015 09:25:37 -0500 (CDT) Christoph Lameter c...@linux.com
wrote:
What's the reason for returning a partial result when ENOMEM? Some
callers will throw away the partial result and simply fail out. If a
caller attempts to go ahead and use the partial result then great, but
On Tue, 31 Mar 2015, Andrew Morton wrote:
This patch doesn't really do anything. I guess nailing down the
interface helps a bit.
Right.
to modules. And it isn't completely obvious, because the return
semantics are weird.
Ok.
What's the reason for returning a partial result when ENOMEM?
On Mon, 30 Mar 2015 09:31:19 -0500 (CDT) Christoph Lameter
wrote:
> After all of the earlier discussions I thought it would be better to
> first get agreement on the basic way to allow implementation of the
> bulk alloc in the common slab code. So this is a revision of the initial
> proposal
On Mon, 30 Mar 2015 09:31:19 -0500 (CDT) Christoph Lameter c...@linux.com
wrote:
After all of the earlier discussions I thought it would be better to
first get agreement on the basic way to allow implementation of the
bulk alloc in the common slab code. So this is a revision of the initial
On Mon, 30 Mar 2015 09:31:19 -0500 (CDT)
Christoph Lameter wrote:
> After all of the earlier discussions I thought it would be better to
> first get agreement on the basic way to allow implementation of the
> bulk alloc in the common slab code. So this is a revision of the initial
> proposal and
After all of the earlier discussions I thought it would be better to
first get agreement on the basic way to allow implementation of the
bulk alloc in the common slab code. So this is a revision of the initial
proposal and it just covers the first patch.
This patch adds the basic infrastructure
After all of the earlier discussions I thought it would be better to
first get agreement on the basic way to allow implementation of the
bulk alloc in the common slab code. So this is a revision of the initial
proposal and it just covers the first patch.
This patch adds the basic infrastructure
On Mon, 30 Mar 2015 09:31:19 -0500 (CDT)
Christoph Lameter c...@linux.com wrote:
After all of the earlier discussions I thought it would be better to
first get agreement on the basic way to allow implementation of the
bulk alloc in the common slab code. So this is a revision of the initial
12 matches
Mail list logo
