Hello!

On Wed, Jun 18, 2014 at 05:00:14PM +0800, Jianjun Zheng wrote:

> At present, alloting memory with size of ngx_slab_max_size causes
>
> 1) an internal fragmentation, size of ngx_slab_max_size, comes into being
>
> 2) the slot with index of (ngx_pagesize_shift - pool->min_shift - 1)
> is the right slot for this size.
>
>
> # HG changeset patch
> # User Jianjun Zheng <codeeply@gmail.com>
> # Date 1403080799 -28800
> # Wed Jun 18 16:39:59 2014 +0800
> # Node ID 1704335dd810e2e2abb2b393b4f7b7c9004c6012
> # Parent ec919574cc14f7781c0ca212cffec586f88eec40
> Core: bugfix for the ngx_slab_max_size case
>
> diff -r ec919574cc14 -r 1704335dd810 src/core/ngx_slab.c
> --- a/src/core/ngx_slab.c Tue Jun 17 16:51:25 2014 +0400
> +++ b/src/core/ngx_slab.c Wed Jun 18 16:39:59 2014 +0800
> @@ -160,7 +160,7 @@
> ngx_uint_t i, slot, shift, map;
> ngx_slab_page_t *page, *prev, *slots;
>
> - if (size >= ngx_slab_max_size) {
> + if (size > ngx_slab_max_size) {
>
> ngx_log_debug1(NGX_LOG_DEBUG_ALLOC, ngx_cycle->log, 0,
> "slab alloc: %uz", size);

Sorry for late reply.

Yes, the patch is right, allocation of ngx_slab_max_size exactly
(aka half page, 2048 bytes on platforms with 4k pages) can be
satisfied from the largest slot and don't need the whole page to
be allocated. While it's a corner case, it's certainly can be
important in some cases and worth fixing.

Committed, thanks.

--
Maxim Dounin
http://nginx.org/

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel