linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: valdis.kletnieks@vt.edu
To: Pintu Agarwal <pintu.ping@gmail.com>
Cc: linux-mm@kvack.org, open list <linux-kernel@vger.kernel.org>,
	kernelnewbies@kernelnewbies.org
Subject: Re: Creating compressed backing_store as swapfile
Date: Mon, 05 Nov 2018 11:12:08 -0500	[thread overview]
Message-ID: <40880.1541434328@turing-police.cc.vt.edu> (raw)
In-Reply-To: <CAOuPNLjuM5qq3go9ZFZcK0G5pQxTQb0DY36xu+8SL4vC4zJntw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2220 bytes --]

On Mon, 05 Nov 2018 20:31:46 +0530, Pintu Agarwal said:
> I wanted to have a swapfile (64MB to 256MB) on my system.
> But I wanted the data to be compressed and stored on the disk in my swapfile.
> [Similar to zram, but compressed data should be moved to disk, instead of RAM].

What platform are you on that you're both storage constrained enough to need
swap, and also so short on disk space that compressing it makes sense?
Understanding the hardware constraints here would help in advising you.

> Note: I wanted to optimize RAM space, so performance is not important
> right now for our requirement.
>
> So, what are the options available, to perform this in 4.x kernel version.
> My Kernel: 4.9.x

Given that this is a greenfield development, why are you picking a kernel
that's 2 years out of date?  You *do* realize that 4.9.135 does *not* contain
all the bugfixes since then, only that relatively small subset that qualify for
'stable' (see Documentation/process/stable-kernel-rules.rst for the gory
details).

One possible total hack would be to simply use a file-based swap area,
but put the file on a filesystem that supports automatic inline compression.

Note that this will probably *totally* suck on performance, because there's
no good way to find where 4K block 11,493 starts inside the compressed
file, so it would have to read/decompress from the file beginning.  Also,
if you write data to a previously unused location (or even a previously used
spot that compressed the 4K page to a different length), you have a bad time
inserting it.  (Note that zram can avoid most of this because it can (a) keep
a table of pointers to where each page starts and (b) it isn't constrained to
writing to 4K blocks on disk, so if the current compression takes a 4K page down
to 1,283 bytes, it doesn't have to care *too* much if it stores that someplace
that crosses a page boundary.

Another thing that you will need to worry about is what happens in low-memory
situations - the time you *most* need to do a swap operation, you may not have
enough memory to do the I/O.  zram basically makes sure it *has* the memory
needed beforehand, and swap directly to pre-allocated disk doesn't need much
additional memory.

[-- Attachment #2: Type: application/pgp-signature, Size: 486 bytes --]

  parent reply	other threads:[~2018-11-05 16:12 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-05 15:01 Pintu Agarwal
2018-11-05 15:58 ` Adam Borowski
2018-11-05 16:07   ` Austin S. Hemmelgarn
2018-11-05 16:14     ` valdis.kletnieks
2018-11-05 16:28       ` Austin S. Hemmelgarn
2018-11-05 16:53         ` valdis.kletnieks
2018-11-05 16:55           ` Austin S. Hemmelgarn
2018-11-08  9:51     ` Pintu Agarwal
2018-11-05 16:12 ` valdis.kletnieks [this message]
2018-11-08  9:46   ` Pintu Agarwal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=40880.1541434328@turing-police.cc.vt.edu \
    --to=valdis.kletnieks@vt.edu \
    --cc=kernelnewbies@kernelnewbies.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=pintu.ping@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox