linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Timofey Titovets <nefelim4ag@gmail.com>
To: linux-btrfs@vger.kernel.org
Cc: Timofey Titovets <nefelim4ag@gmail.com>
Subject: [RFC PATCH v2 0/2] Btrfs: add compression heuristic
Date: Mon, 26 Jun 2017 04:24:54 +0300	[thread overview]
Message-ID: <20170626012456.19872-1-nefelim4ag@gmail.com> (raw)

Today btrfs use simple logic to make decision
compress data or not:
Selected compression
algorithm try compress data and if this save some space
store that extent as compressed.

It's Reliable way to detect uncompressible data
but it's will waste/burn cpu time for
bad/un-compressible data and add latency.

This way also add additional pressure on
memory subsustem as for every compressed write
btrfs need to allocate some buffered pages and
reuse compression workspace.

This is quite efficient, but not free.

So, try create basic heuristic framework,
this heuristic code will analizy data on the fly
before call of compression code,
can detect uncompressible data and advice to skip it.

I leave comments with description in code,
but i will try describe that short.
Heuristic have several internal layers:
1. Get sample data - this is cpu expensive
to analize whole stream, so let's get some
big enough sample from input data
Scaling:
In data: 128K  64K   32K   4K
Sample:  4096b 3072b 2048b 1024b
2. For performance reason and for reuse it in 7th level
copy selected data to sample buffer
3. Count every byte type in sample buffer
4. Count how many types of bytes we find
If it's not many - data will be easy compressible
5. Count character core set size, i.e.
which characters use 90% of input stream
If core set small (1-50 different types)
Data easy compressible
If big (200-256) - data probably can't be compressed
6. If above methods are fail to make decision,
try compute shannon entropy
If entropy are small - data will be easy compressible
If not - go to 7th
7. Entropy can't detect repeated strings of bytes
So try look at the data for detect repeated bytes
Compute a difference between frequency of bytes from
coreset and between frequency of pair of that bytes
If sum of that defferent from zero and entropy and not
big, give compression code a try
If entropy are High 7.2/8 - 8/8 (> 90%), and if we find BIG enough
difference between frequency of a pairs and characters
Give compression code a try

7th level needed for decreasing false negative returns,
where data can be compressed (like ~131072b -> ~87000b ~ 0.66), but not
so easy.

(this above code as i see it's forbidden compression like:
131072b -> ~110000b)

Shannon entropy use log2(a/b) function,
I did a try replace that with int_log2(a)-int_log2(b), but
integer realization of log2 show a lack of accuracy (+-7-10%) in our case.
So i precalculate some input/output values (1/131072 - 1/1) and create log2_lshift16();
I already decrease lines of that function from 1200 -> 200
for save memory (and lose some accuracy), so with precomputed function
I get +- 0.5-2% of accuracy (in compare to normal "true" float log2 shannon)

Thanks.

P.S.
I made only stability tests at now, all works stable.
About performance:
In userspace realization of that algorithm, which
iterate over data by 128kb block and do Mmap() of file, it
show ~4GiB/s over in memory (cached) data in one stream.
For i5-4200M && DDR3.

So i expect to not hurt compression performance.

I've also duplicate patch set to:
https://github.com/Nefelim4ag/linux

log2_lshift() - tested by log2_generator
https://github.com/Nefelim4ag/Entropy_Calculation

P.S.S.
Sorry for my bad english and may be for ugly code.
I do my best, thanks.


Changes since v1:
  - Fixes of checkpatch.pl warnings/errors
  - Use div64_u64() instead of "/"
  - Make log2_lshift16() more like binary tree as suggested by:
    Adam Borowski <kilobyte@angband.pl>

Timofey Titovets (2):
  Btrfs: add precomputed log2()
  Btrfs: add heuristic method for make decision compress or not compress

 fs/btrfs/Makefile        |   2 +-
 fs/btrfs/heuristic.c     | 264 ++++++++++++++++++++++++++++++++++++++++++++
 fs/btrfs/heuristic.h     |  13 +++
 fs/btrfs/inode.c         |  37 ++++---
 fs/btrfs/log2_lshift16.c | 278 +++++++++++++++++++++++++++++++++++++++++++++++
 fs/btrfs/log2_lshift16.h |  11 ++
 6 files changed, 590 insertions(+), 15 deletions(-)
 create mode 100644 fs/btrfs/heuristic.c
 create mode 100644 fs/btrfs/heuristic.h
 create mode 100644 fs/btrfs/log2_lshift16.c
 create mode 100644 fs/btrfs/log2_lshift16.h

--
2.13.1

             reply	other threads:[~2017-06-26  1:25 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-26  1:24 Timofey Titovets [this message]
2017-06-26  1:24 ` [RFC PATCH v2 1/2] Btrfs: add precomputed log2() Timofey Titovets
2017-06-26  1:24 ` [RFC PATCH v2 2/2] Btrfs: add heuristic method for make decision compress or not compress Timofey Titovets

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=20170626012456.19872-1-nefelim4ag@gmail.com \
    --to=nefelim4ag@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).