On Thu, 29 Jan 2015 16:44:43 +0900
Joonsoo Kim wrote:
> On Wed, Jan 28, 2015 at 09:30:56AM -0600, Christoph Lameter wrote:
> > On Wed, 28 Jan 2015, Joonsoo Kim wrote:
> >
[...]
> >
> > The default when no options are specified is to first exhaust the node
> > partial objects, then allocate new
On Thu, 29 Jan 2015 16:44:43 +0900
Joonsoo Kim iamjoonsoo@lge.com wrote:
On Wed, Jan 28, 2015 at 09:30:56AM -0600, Christoph Lameter wrote:
On Wed, 28 Jan 2015, Joonsoo Kim wrote:
[...]
The default when no options are specified is to first exhaust the node
partial objects, then
On Wed, Jan 28, 2015 at 09:30:56AM -0600, Christoph Lameter wrote:
> On Wed, 28 Jan 2015, Joonsoo Kim wrote:
>
> > > GFP_SLAB_ARRAY new is best for large quantities in either allocator since
> > > SLAB also has to construct local metadata structures.
> >
> > In case of SLAB, there is just a
On Wed, 28 Jan 2015, Joonsoo Kim wrote:
> > GFP_SLAB_ARRAY new is best for large quantities in either allocator since
> > SLAB also has to construct local metadata structures.
>
> In case of SLAB, there is just a little more work to construct local metadata
> so
> GFP_SLAB_ARRAY_NEW would not
On Wed, 28 Jan 2015, Joonsoo Kim wrote:
GFP_SLAB_ARRAY new is best for large quantities in either allocator since
SLAB also has to construct local metadata structures.
In case of SLAB, there is just a little more work to construct local metadata
so
GFP_SLAB_ARRAY_NEW would not show
On Wed, Jan 28, 2015 at 09:30:56AM -0600, Christoph Lameter wrote:
On Wed, 28 Jan 2015, Joonsoo Kim wrote:
GFP_SLAB_ARRAY new is best for large quantities in either allocator since
SLAB also has to construct local metadata structures.
In case of SLAB, there is just a little more work
2015-01-28 1:57 GMT+09:00 Christoph Lameter :
> On Tue, 27 Jan 2015, Joonsoo Kim wrote:
>
>> IMHO, exposing these options is not a good idea. It's really
>> implementation specific. And, this flag won't show consistent performance
>> according to specific slab implementation. For example, to get
On Tue, 27 Jan 2015, Joonsoo Kim wrote:
> IMHO, exposing these options is not a good idea. It's really
> implementation specific. And, this flag won't show consistent performance
> according to specific slab implementation. For example, to get best
> performance, if SLAB is used,
On Fri, Jan 23, 2015 at 03:37:28PM -0600, Christoph Lameter wrote:
> This patch adds the basic infrastructure for alloc / free operations
> on pointer arrays. It includes a fallback function that can perform
> the array operations using the single alloc and free that every
> slab allocator
On Fri, Jan 23, 2015 at 03:37:28PM -0600, Christoph Lameter wrote:
This patch adds the basic infrastructure for alloc / free operations
on pointer arrays. It includes a fallback function that can perform
the array operations using the single alloc and free that every
slab allocator performs.
2015-01-28 1:57 GMT+09:00 Christoph Lameter c...@linux.com:
On Tue, 27 Jan 2015, Joonsoo Kim wrote:
IMHO, exposing these options is not a good idea. It's really
implementation specific. And, this flag won't show consistent performance
according to specific slab implementation. For example, to
On Tue, 27 Jan 2015, Joonsoo Kim wrote:
IMHO, exposing these options is not a good idea. It's really
implementation specific. And, this flag won't show consistent performance
according to specific slab implementation. For example, to get best
performance, if SLAB is used, GFP_SLAB_ARRAY_LOCAL
This patch adds the basic infrastructure for alloc / free operations
on pointer arrays. It includes a fallback function that can perform
the array operations using the single alloc and free that every
slab allocator performs.
Allocators must define _HAVE_SLAB_ALLOCATOR_OPERATIONS in their
header
This patch adds the basic infrastructure for alloc / free operations
on pointer arrays. It includes a fallback function that can perform
the array operations using the single alloc and free that every
slab allocator performs.
Allocators must define _HAVE_SLAB_ALLOCATOR_OPERATIONS in their
header
14 matches
Mail list logo
