linux-kernel - Re: [PATCH] zsmalloc: consider ZS_ALMOST

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150710052113.GA11329@bgram>
Date:	Fri, 10 Jul 2015 14:21:13 +0900
From:	Minchan Kim <minchan@...nel.org>
To:	Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
	Nitin Gupta <ngupta@...are.org>, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org
Subject: Re: [PATCH] zsmalloc: consider ZS_ALMOST_FULL as migrate source

On Fri, Jul 10, 2015 at 01:19:29PM +0900, Sergey Senozhatsky wrote:
> On (07/10/15 11:29), Minchan Kim wrote:
> > Good question.
> > 
> > My worry was failure of order-0 page allocation in zram-swap path
> > when memory presssure is really heavy but I didn't insist to you
> > from sometime. The reason I changed my mind was
> > 
> > 1. It's almost dead system if there is no order-0 page
> > 2. If old might be working well, it's not our design, just luck.
> 
> I mean I find your argument that some level of fragmentation
> can be of use to be valid, to some degree.

The benefit I had in mind was to prevent failure of allocation.

> 
> 
> hm... by the way,
> 
> unsigned long zs_malloc(struct zs_pool *pool, size_t size)
> {
> ...
>    size += ZS_HANDLE_SIZE;
>    class = pool->size_class[get_size_class_index(size)];
> ...
>    if (!first_page) {
> 	   spin_unlock(&class->lock);
> 	   first_page = alloc_zspage(class, pool->flags);
> 	   if (unlikely(!first_page)) {
> 		   free_handle(pool, handle);
> 		   return 0;
> 	   }
>    ...
> 
> I'm thinking now, does it make sense to try harder here? if we
> failed to alloc_zspage(), then may be we can try any of unused
> objects from a 'upper' (larger/next) class?  there might be a
> plenty of them.

I actually thought about that but I didn't have any report from
community and product division of my compamy until now.
But with auto-compaction, the chance would be higher than old
so let's keep an eye on it(I think users can find it easily because
swap layer emits "write write failure").

If it happens(ie, any report from someone), we could try to compact
and then if it fails, we could fall back to upper class as a last
resort.

Thanks.
> 
> 	-ss
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/