Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1243313 > unrolled thread

Re: [PATCHv2 0/3] align zpool/zbud/zsmalloc on the api

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCHv2 0/3] align zpool/zbud/zsmalloc on the api Dan Streetman <ddstreet@ieee.org> - 2015-10-09 14:40 +0200
    Re: [PATCHv2 0/3] align zpool/zbud/zsmalloc on the api Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2015-10-14 03:30 +0200

#1243313 — Re: [PATCHv2 0/3] align zpool/zbud/zsmalloc on the api

On Sat, Sep 26, 2015 at 4:04 AM, Vitaly Wool <vitalywool@gmail.com> wrote:
> Here comes the second iteration over zpool/zbud/zsmalloc API alignment.
> This time I divide it into three patches: for zpool, for zbud and for zsmalloc :)
> Patches are non-intrusive and do not change any existing functionality. They only
> add up stuff for the alignment purposes.

While I agree with what the patches do - simply change zram to use
zpool so zbud is an option - I also understand (I think) Minchan's
reluctance to ack them.  From his point of view, with zram, there is
no upside to using zpool; zsmalloc has better storage density than
zbud.  And without compaction, zbud and zsmalloc should be
*approximately* as deterministic, at least theoretically.  So changing
zram to use zpool only introduces a layer between zram and zsmalloc,
creating more work for him to update both zram and zsmalloc in the
future; adding a new feature/interface to zsmalloc will mean he also
has to update zpool and get additional ack's; he can add new features
to zram/zsmalloc now relatively uncontested.  I'm not trying to say
that's a bad thing, just that I can understand reluctance to add
complexity and additional future work, when in doubt of the benefit.
So I suspect you aren't going to get an ack from him until you show
him the specific benefit of using zbud, using hard data, and we all
figure out exactly why zbud is better in some situations.  And without
his ack, you're almost certainly not going to get zram or zsmalloc
patches in.

One thing I will say in general, and Seth has said this before too, is
that zbud is supposed to be the simple, reliable, consistent driver;
it won't get you the best storage efficiency, but it should be very
consistent in doing what it does, and it shouldn't change (much) from
one kernel version to another.  Opposed to that is zsmalloc, which is
supposed to get the best storage density, and is updated rather often
to get closer to that goal.  It has more knobs (at least internally),
and its code can change significantly from one kernel to another,
resulting in different (usually better) storage efficiency, but
possibly also resulting in less deterministic behavior, and more
processing overhead.  So I think even without hard numbers to compare
zbud and zsmalloc under zram, your general argument that some people
want stability over efficiency is not something to be dismissed; zbud
and zsmalloc clearly have different goals, and zsmalloc can't simply
be patched to be as consistent as zbud across kernel versions.  That's
not its goal; its goal is to achieve maximum storage efficiency.

Specifically regarding the determinism of each; obviously compaction
will have an impact, since it takes cpu cycles to do the compaction.
I don't know how much impact, but I think at minimum it would make
sense to add a module param to zsmalloc to allow disabling compaction.
But even without compaction, there is an important difference between
zbud and zsmalloc; zbud will never alloc more than 1 page when it
needs more storage, while zsmalloc will alloc between 1 and
ZS_MAX_PAGES_PER_ZSPAGE (currently 4) pages when it needs more
storage.  So in the worst case (if memory is tight and alloc_page()
takes a while), zsmalloc could take up to 4 times as long as zbud to
store a page.  Now, that should average out, where zsmalloc doesn't
need to alloc as many times as zbud (since it allocs more at once),
but on the small scale there will be less consistency of page storage
times with zsmalloc than zbud; at least, theoretically ;-)

I suggest you work with Minchan to find out what comparison data he
wants to see, to prove zbud is more stable/consistent under a certain
workload (and/or across kernel versions).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1246240

Sorry for long reply.

On (10/09/15 08:36), Dan Streetman wrote:
[..]
> Specifically regarding the determinism of each; obviously compaction
> will have an impact, since it takes cpu cycles to do the compaction.
> I don't know how much impact, but I think at minimum it would make
> sense to add a module param to zsmalloc to allow disabling compaction.

Well, this was on my list of things TODO; and, BTW, this was *ONE OF*
the reason I added bool flag `->shrinker_enabled'.

static unsigned long zs_shrinker_count(struct shrinker *shrinker,
		struct shrink_control *sc)
{
	...
	if (!pool->shrinker_enabled)
		return 0;
	...
}

So, technically, it's easy. I'm not sure, though, that I want to export
this low level knob. It sort of makes sense, but at the same time a bit
tricky.

> But even without compaction, there is an important difference between
> zbud and zsmalloc; zbud will never alloc more than 1 page when it
> needs more storage, while zsmalloc will alloc between 1 and
> ZS_MAX_PAGES_PER_ZSPAGE (currently 4) pages when it needs more
> storage.  So in the worst case (if memory is tight and alloc_page()
> takes a while), zsmalloc could take up to 4 times as long as zbud to
> store a page.
>

hm... zsmalloc release zspage once it becomes empty, which happens:
a) when zspage receives 'final' zs_free() (no more objects in use)
   and turns into a ZS_EMPTY zspage
b) when compaction moves all of its object to other zspages and, thus,
   the zspage becomes ZS_EMPTY

And, basically, this `allocate ZS_MAX_PAGES_PER_ZSPAGE pages' penalty
hits (to some degree) us even if we are not so tight on memory.


So... *May be* it makes some sense to guarantee (well, via a special
knob) that each class has no less than N unused objects (hot-cache),
which may be (but not necessarily is) an equivalent of keeping M
ZS_EMPTY zspage(-s) in the class. IOW, avoid free_zspage() if that will
result in K alloc_page() shortly, simply because we end up having just
1 or 2 unused objects in the class.

I can understand that some workloads care less about memory efficiency.


Looks like I finally have more time this week so I'll try to take a
look why zsmalloc makes Vitaly so unhappy.

	-ss

> Now, that should average out, where zsmalloc doesn't
> need to alloc as many times as zbud (since it allocs more at once),
> but on the small scale there will be less consistency of page storage
> times with zsmalloc than zbud; at least, theoretically ;-)
> 
> I suggest you work with Minchan to find out what comparison data he
> wants to see, to prove zbud is more stable/consistent under a certain
> workload (and/or across kernel versions).
> 
> --
> 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/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web