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

[Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>]

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, 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>