Re: [PATCH V1 0/3] drivers/staging: kztmem: dynamic page cache/swap compression

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dan Magenheimer <dan.magenheimer <at> oracle.com> writes:
> Kztmem (see kztmem.c) provides both "host" services (setup and
> core memory allocation) for a single client for the generic tmem
> code plus two different PAM implementations:
> 
> A. "compression buddies" ("zbud") which mates compression with a
>    shrinker interface to store ephemeral pages so they can be
>    easily reclaimed; compressed pages are paired and stored in
>    a physical page, resulting in higher internal fragmentation
> B. a shim to xvMalloc [8] which is more space-efficient but
>    less receptive to page reclamation, so is fine for persistent
>    pages

One feature that was present in compcache before it became zcache and zram
was the ability to have a backing store on disk. I personally would find it
interesting if:
 - 'True' swap was reimplemented as a frontswap backend
 - Multiple frontswap backends could be active at any time (Is this already
possible?)
 - Frontswap backends could provide a 'cost' metric, possibly based on
latency
 - Frontswap backends could 'delegate' pages to the backend with the
next-highest cost

Thus, the core kernel could put pages into kztmem, which could then delegate
to disk-based swap (possibly storing the buddy-compressed page, for IO and
space reduction)

A backend might 'hand off' a page if it is full, or for backend-specific
reasons (like if it compressed badly).

If a backend delegates pages which went a long time without being accessed,
congratulations - you have a hierarchical storage manager. This bit makes me
think the idea of delegation may be worth extending to cleancache.

Implementing traditional disk-based swap as a frontswap backend would strike
me as being a good way to test the flexibility (and performance) of
frontswap, and the traditional 'priority' parameter for swap could probably
be handled just by adding it to the base 'cost' of the swap backend.

There is the question of what to do if two backends have the same cost.
Using a round-robin system would probably be the simplest option, and
hopefully not too far off from the 'striping' that goes on when a user
specifies two swap devices with the same priority.

Thoughts?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]