From: Nitin Gupta <ngupta@vflare.org>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Greg KH <greg@kroah.com>,
Andrew Morton <akpm@linux-foundation.org>,
Hugh Dickins <hugh.dickins@tiscali.co.uk>,
Pekka Enberg <penberg@cs.helsinki.fi>,
Marcin Slusarz <marcin.slusarz@gmail.com>,
Ed Tomlinson <edt@aei.ca>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>,
linux-mm-cc <linux-mm-cc@laptop.org>
Subject: Re: [PATCH 2/3] virtual block device driver (ramzswap)
Date: Thu, 24 Sep 2009 22:24:50 +0530 [thread overview]
Message-ID: <4ABBA45A.8010305@vflare.org> (raw)
In-Reply-To: <20090924141135.833474ad.kamezawa.hiroyu@jp.fujitsu.com>
On 09/24/2009 10:41 AM, KAMEZAWA Hiroyuki wrote:
> On Tue, 22 Sep 2009 10:26:53 +0530
> Nitin Gupta <ngupta@vflare.org> wrote:
>
> <snip>
>> + if (unlikely(clen > max_zpage_size)) {
>> + if (rzs->backing_swap) {
>> + mutex_unlock(&rzs->lock);
>> + fwd_write_request = 1;
>> + goto out;
>> + }
>> +
>> + clen = PAGE_SIZE;
>> + page_store = alloc_page(GFP_NOIO | __GFP_HIGHMEM);
> Here, and...
>
>> + if (unlikely(!page_store)) {
>> + mutex_unlock(&rzs->lock);
>> + pr_info("Error allocating memory for incompressible "
>> + "page: %u\n", index);
>> + stat_inc(rzs->stats.failed_writes);
>> + goto out;
>> + }
>> +
>> + offset = 0;
>> + rzs_set_flag(rzs, index, RZS_UNCOMPRESSED);
>> + stat_inc(rzs->stats.pages_expand);
>> + rzs->table[index].page = page_store;
>> + src = kmap_atomic(page, KM_USER0);
>> + goto memstore;
>> + }
>> +
>> + if (xv_malloc(rzs->mem_pool, clen + sizeof(*zheader),
>> + &rzs->table[index].page, &offset,
>> + GFP_NOIO | __GFP_HIGHMEM)) {
>
> Here.
>
> Do we need to wait until here for detecting page-allocation-failure ?
> Detecting it here means -EIO for end_swap_bio_write()....unhappy
> ALERT messages etc..
>
> Can't we add a hook to get_swap_page() for preparing this ("do we have
> enough pool?") and use only GFP_ATOMIC throughout codes ?
> (memory pool for this swap should be big to some extent.)
>
Yes, we do need to wait until this step for detecting alloc failure since
we don't really know when pool grow will (almost) surely wail.
What we can probably do is, hook into OOM notify chain (oom_notify_list)
and whenever we get this callback, we can start sending pages directly
to backing swap and do not even attempt to do any allocation.
>>From my user support experience for heavy swap customers, extra memory allocation for swapping out is just bad...in many cases.
> (*) I know GFP_IO works well to some extent.
>
We cannot use GFP_IO here as it can cause a deadlock:
ramzswap alloc() --> not enough memory, try to reclaim some --> swap out ...
... some pages to ramzswap --> ramzswap alloc()
Thanks,
Nitin
--
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>
next prev parent reply other threads:[~2009-09-24 16:55 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-22 4:56 [PATCH 0/3] compcache: in-memory compressed swapping v4 Nitin Gupta
2009-09-22 4:56 ` [PATCH 1/3] xvmalloc memory allocator Nitin Gupta
2009-09-22 4:56 ` [PATCH 2/3] virtual block device driver (ramzswap) Nitin Gupta
2009-09-24 5:11 ` KAMEZAWA Hiroyuki
2009-09-24 16:54 ` Nitin Gupta [this message]
2009-09-24 23:46 ` KAMEZAWA Hiroyuki
2009-09-22 4:56 ` [PATCH 3/3] documentation Nitin Gupta
2009-10-08 22:57 ` Greg KH
2009-10-08 22:58 ` Greg KH
2009-09-22 6:13 ` [PATCH 0/3] compcache: in-memory compressed swapping v4 Pekka Enberg
2009-09-22 8:36 ` Nitin Gupta
2009-09-22 15:37 ` Greg KH
2009-09-22 15:52 ` Nitin Gupta
2009-09-23 0:40 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4ABBA45A.8010305@vflare.org \
--to=ngupta@vflare.org \
--cc=akpm@linux-foundation.org \
--cc=edt@aei.ca \
--cc=greg@kroah.com \
--cc=hugh.dickins@tiscali.co.uk \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm-cc@laptop.org \
--cc=linux-mm@kvack.org \
--cc=marcin.slusarz@gmail.com \
--cc=penberg@cs.helsinki.fi \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).