[linux-mm-cc] First experience of compressed cache

[John McCabe-Dansted]

If you are busy, perhaps there are tasks you could delegate?

BTW, are there parts of the kernel other than compcache that could
benefit from TLSF?

On Wed, Apr 2, 2008 at 5:38 PM, Nitin Gupta <nitingupta910 at gmail.com> wrote:
>  Flag GFP_KERNEL has nothing to do with slab sizes available. It simply
>  means that
>  the allocation can trigger I/O (swapping, flushing to filesystem) if
>  thats required to
>  satisfy the request.

Ah, so there is no easy way for a module to add new slice sizes to kmalloc?

There are many slice sizes listed in /proc/slabinfo (On 2.6.23+).
Kmalloc only uses the ones named kmalloc-*?

> >  >  Your patch almost serves the purpose. But it will be much more convincing if we
> >  >  can show TLSF vs Kmalloc perf over a period of time instead of just

They asked for numbers. We have numbers:
99.9% Kmalloc worst-case
42% A typical load for Kmalloc under compcache
30% TLSF worst case [1]
15% TLSF synthetic load [1]
<5%  TLSF typical compache load.
[1] http://rtportal.upv.es/rtmalloc/files/tlsf_paper_spe_2007.pdf

(Do these seem right to you?)

These numbers seem sufficient to demonstrate that vanilla Kmalloc is
unsuited to compcache. It would seem better to now focus on the
remaining issues Peter raised with TLSF:

On Tue, Mar 25, 2008 at 12:26 AM, Peter Zijlstra <a.p.zijlstra at chello.nl> wrote:
>  Yeah, it also suffers from a horrible coding style,

Do you know what he means? Could I fix this?

> can use excessive  amounts of vmalloc space,

We'd need 32K slabs to get <5% fragmentation with a slice allocator.
Allocating thousands of 32K slabs would probably would create as much
work for the VM as a bit of vmalloc?

(Also I cap size of ramzswap0 to 300M to keep vmalloc size a reasonable 150M).

> isn't hooked into the reclaim process as an
>  allocator should be

Does TLSF hold onto many pages?
... compared to the number of pages it saves?

Could TLSF be hooked into reclaim process?
... now? Once it is merged into kernel?

> and has a severe lack of per-cpu data making it a
>  pretty big bottleneck on anything with more than a few cores.

Probably not an issue for us. Most of our work is probably in
compression/decompression, and a 256-way SMP cluster that spends most
of its time swapping is far from our primary use case.

>  Now, it might be needed, might work better, and the scalability issue
>  might not be a problem when used for swap, but still, you don't treat
>  any of these points in your changelog.

Seems like we can make Peter happy mostly just by adding stuff to the changelog.

-- 
John C. McCabe-Dansted
PhD Student
University of Western Australia