slab cache

slab cache

[David Chow]

Dear all,

I am trying to improve the speed of my fs code. I have a fixed sized 
buffer for my fs, I currently use kmalloc for allocation of buffers 
greater than 4k, use get_free_page for 4k buffers and vmalloc for large 
buffers. Is there any benefits using the slab cache? If so whats the 
difference of using slab cache than kmalloc? Thanks for comments.

regards,
David

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: slab cache

[Stephen C. Tweedie]

Hi,

On Sun, Jun 09, 2002 at 10:52:46PM +0800, David Chow wrote:
 
> I am trying to improve the speed of my fs code. I have a fixed sized 
> buffer for my fs, I currently use kmalloc for allocation of buffers 
> greater than 4k, use get_free_page for 4k buffers and vmalloc for large 
> buffers.

Allocations larger than pagesize always put a higher stress on the VM
and reduce performance.  Your best bet for top performance will be
simply to perform no allocations larger than pagesize.  You can use a
slab cache for those allocations if you want, and that may have some
advantages depending on the locality of allocations in your code.

Using 4k buffers does not limit your ability to use larger data
structures --- you can still chain 4k buffers together by creating an
array of struct page* pointers via which you can access the data.

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: slab cache

[David Chow]

Stephen C. Tweedie wrote:

>Hi,
>
>On Sun, Jun 09, 2002 at 10:52:46PM +0800, David Chow wrote:
> 
>
>>I am trying to improve the speed of my fs code. I have a fixed sized 
>>buffer for my fs, I currently use kmalloc for allocation of buffers 
>>greater than 4k, use get_free_page for 4k buffers and vmalloc for large 
>>buffers.
>>
>
>Allocations larger than pagesize always put a higher stress on the VM
>and reduce performance.  Your best bet for top performance will be
>simply to perform no allocations larger than pagesize.  You can use a
>slab cache for those allocations if you want, and that may have some
>advantages depending on the locality of allocations in your code.
>
>Using 4k buffers does not limit your ability to use larger data
>structures --- you can still chain 4k buffers together by creating an
>array of struct page* pointers via which you can access the data.
>
>--Stephen
>
Yes, but for me it is very hard. When doing compression code, most of 
the stuff is not even byte aligned, most of them might be bitwise 
operated, it need very change to existing code. I've already use 
get_free_page to allocate memory that is 4k to avoid some stress to the 
vm, I have no idea about the difference of get_fee_page and the slab 
cache. All my linear buffers stuff is already using array of page 
pointers, if there any benefits for changing them to use slabcache? 
Please advice, thanks.

regards,
David Chow


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: slab cache

[Stephen C. Tweedie]

Hi,

On Wed, Jun 12, 2002 at 11:05:29PM +0800, David Chow wrote:

> >Using 4k buffers does not limit your ability to use larger data
> >structures --- you can still chain 4k buffers together by creating an
> >array of struct page* pointers via which you can access the data.

> Yes, but for me it is very hard. When doing compression code, most of 
> the stuff is not even byte aligned, most of them might be bitwise 
> operated, it need very change to existing code. 

Perhaps, but the VM basically doesn't give you any primitives that you
can use for arbitrarily large chunks of linear data; things like
vmalloc are limited in the amount of data they can use, total, and it
is _slow_ to set up and tear down vmalloc mappings.

> get_free_page to allocate memory that is 4k to avoid some stress to the 
> vm, I have no idea about the difference of get_fee_page and the slab 
> cache. All my linear buffers stuff is already using array of page 
> pointers, if there any benefits for changing them to use slabcache? 
> Please advice, thanks.

It might be if you are allocating and deallocating large numbers of
them in bunches, since the slab cache can then keep a few pages cached
for immediate reuse rather than going to the global page allocator for
every single page.  The per-cpu slab stuff would also help to keep the
pages concerned hot in the cache of the local cpu, and that is likely
to be a big performance improvement in some cases.

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: slab cache

[David Chow]

Stephen C. Tweedie wrote:

>Hi,
>
>On Wed, Jun 12, 2002 at 11:05:29PM +0800, David Chow wrote:
>
>>>Using 4k buffers does not limit your ability to use larger data
>>>structures --- you can still chain 4k buffers together by creating an
>>>array of struct page* pointers via which you can access the data.
>>>
>
>>Yes, but for me it is very hard. When doing compression code, most of 
>>the stuff is not even byte aligned, most of them might be bitwise 
>>operated, it need very change to existing code. 
>>
>
>Perhaps, but the VM basically doesn't give you any primitives that you
>can use for arbitrarily large chunks of linear data; things like
>vmalloc are limited in the amount of data they can use, total, and it
>is _slow_ to set up and tear down vmalloc mappings.
>
>>get_free_page to allocate memory that is 4k to avoid some stress to the 
>>vm, I have no idea about the difference of get_fee_page and the slab 
>>cache. All my linear buffers stuff is already using array of page 
>>pointers, if there any benefits for changing them to use slabcache? 
>>Please advice, thanks.
>>
>
>It might be if you are allocating and deallocating large numbers of
>them in bunches, since the slab cache can then keep a few pages cached
>for immediate reuse rather than going to the global page allocator for
>every single page.  The per-cpu slab stuff would also help to keep the
>pages concerned hot in the cache of the local cpu, and that is likely
>to be a big performance improvement in some cases.
>
>--Stephen
>

Thanks for comment, since you mention about cache, do you mean CPU L2 
caches? I don't use to dynamic alloc and dealloc pages, I have a fixed 
sized cache per CPU, even using vmalloc I will only do it only once 
during module initialize, and dealloc only on unload, so the performance 
about allocation does not matter me, but it would be interesting to do 
something to keep those allocations higher chance to cached by the CPU's 
L2 cache. I experience 512K cache CPU's are lot faster .

-- David

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: slab cache

[Stephen C. Tweedie]

Hi,

On Fri, Jun 14, 2002 at 12:34:12AM +0800, David Chow wrote:

> Thanks for comment, since you mention about cache, do you mean CPU L2 
> caches? I don't use to dynamic alloc and dealloc pages, I have a fixed 
> sized cache per CPU, even using vmalloc I will only do it only once 
> during module initialize, and dealloc only on unload, 

In that case, slab won't have anything to offer you over basic use of
get_free_pages().

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/