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: <20150710041929.GC692@swordfish>
Date:	Fri, 10 Jul 2015 13:19:29 +0900
From:	Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To:	Minchan Kim <minchan@...nel.org>
Cc:	Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
	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 (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.


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.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ