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